The previous "parse-opt"ification broke git-apply reading from the
standard input. "git apply A - C <B" is supposed to read patches from
files A, B and C in this order.
Before "parse-opt"ification, we used be able to:
git apply --stat - --apply <A B
to read the patch from file A, showing only the diffstat, and then read the
patch from file B, showing the diffstat and actually applying it. Even
with this fix we cannot do that anymore, but that is so crazy use case I
do not think anybody sane relied on such a broken behaviour.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit teaches Git to produce diff output using the patience diff
algorithm with the diff option '--patience'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Accept -- as an "end of options" marker even when using --no-index.
Previously, the -- triggered a "normal" index/tree diff and subsequently
failed because of the unrecognized (in that mode) --no-index.
Note that the second loop can treat '--' as a normal option, because
the preceding checks ensure it is the third-to-last argument.
While at it, fix the parsing of "-q" option in --no-index mode as well.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 0cf73755 (unpack-trees.c: assume submodules are clean during
check-out) changed an argument to verify_absent from 'path' to 'ce',
which is however shadowed by a local variable of the same name.
The bug triggers if verify_absent is used on a tree entry, for which
the index contains one or more subsequent directories of the same
length. The affected subdirectories are removed from the index. The
testcase included in this commit bisects to 55218834 (checkout: do not
lose staged removal), which reveals the bug in this case, but is
otherwise unrelated.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 203a2fe1 (Allow callers of unpack_trees() to handle failure)
changed the "die on error" behavior to "return failure code".
verify_absent did not handle errors returned by
verify_clean_subdirectory, however.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Mac OS X and possibly BSDs, /bin/pwd reads PWD from the environment if
available and shows the logical path by default rather than the physical
one.
Unset PWD before running /bin/pwd in both cd_to_toplevel and its test.
Still use the external /bin/pwd because in my Bash on Linux, the builtin
pwd prints the same result whether or not PWD is set.
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
Tested-by: Wincent Colaiuta <win@wincent.com> (on Mac OS X 10.5.5)
Tested-by: Marcel Koeppen <git-dev@marzelpan.de> (on Mac OS X 10.5.6)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It comes quite as a surprise to an unsuspecting Git user that calling
"git add submodule/file" (which is a mistake, alright) _removes_
the submodule in the index, and adds the file. Instead, complain loudly.
While at it, be nice when the user said "git add submodule/" which is
most likely the consequence of tab-completion, and stage the submodule,
instead of trying to add the contents of that directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With options such as "--all --since=2.weeks.ago", annotated tags used to
be included, when they should have been excluded. The reason is that we
heavily abuse the revision walker to determine what needs to be included
or excluded. And the revision walker does not show tags at all (and
therefore never marks tags as uninteresting).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git checkout -b newbranch $commit^{tree}" mistakenly created a new branch
rooted at the current HEAD, because in that case, the two structure fields
used to see if the command was invoked without any argument (hence it
needs to default to checking out the HEAD) were populated incorrectly.
Upon seeing a command line argument that we took as a rev, we should store
that string in new.name, even if that does not name a commit. This will
correctly trigger the existing safety logic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
A git patch that does not change the executable bit records the mode bits
on its "index" line. "git apply" used to interpret this mode exactly the
same way as it interprets the mode recorded on "new mode" line, as the
wish by the patch submitter to set the mode to the one recorded on the
line.
The reason the mode does not agree between the submitter and the receiver
in the first place is because there is _another_ commit that only appears
on one side but not the other since their histories diverged, and that
commit changes the mode. The patch has "index" line but not "new mode"
line because its change is about updating the contents without affecting
the mode. The application of such a patch is an explicit wish by the
submitter to only cherry-pick the commit that updates the contents without
cherry-picking the commit that modifies the mode. Viewed this way, the
current behaviour is problematic, even though the command does warn when
the mode of the path being patched does not match this mode, and a careful
user could detect this inconsistencies between the patch submitter and the
patch receiver.
This changes the semantics of the mode recorded on the "index" line;
instead of interpreting it as the submitter's wish to set the mode to the
recorded value, it merely informs what the mode submitter happened to
have, and the presense of the "index" line is taken as submitter's wish to
keep whatever the mode is on the receiving end.
This is based on the patch originally done by Alexander Potashev with a
minor fix; the tests are mine.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge two hunks if there is only the specified number of otherwise unshown
context between them. For --inter-hunk-context=1, the resulting patch has
the same number of lines but shows uninterrupted context instead of a
context header line in between.
Patches generated with this option are easier to read but are also more
likely to conflict if the file to be patched contains other changes.
This patch keeps the default for this option at 0. It is intended to just
make the feature available in order to see its advantages and downsides.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"Assume unchanged" bit means "please pretend that I have never touched
this file", so if user removes the file, we should not care.
This patch teaches "git grep" to use cache version in such
situations. External grep case has not been fixed yet. But given that
on the platform that CE_VALID bit may be used like Windows, external
grep is not available anyway, I would wait for people to raise their
hands before touching it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 212945d4 ("Teach git-describe to verify annotated tag names
before output") git-describe learned how to output a warning if
an annotated tag object was matched but its internal name doesn't
match the local ref name.
However, "git describe --all" causes the local ref name to be
prefixed with "tags/", so we need to skip over this prefix before
comparing the local ref name with the name recorded inside of the
tag object.
Patch-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a file was renamed in one branch, but deleted in the other, one
should expect the index to contain an unmerged entry, namely the
target of the rename. Make it so.
Noticed by Constantine Plotnikov.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The script 'git notes' allows you to edit and show commit notes, by
calling either
git notes show <commit>
or
git notes edit <commit>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We cleaned up lockfiles upon receiving the usual suspects HUP, TERM, QUIT
but a wicked user could kill us of asphyxiation by piping our output to a
pipe that does not read. Protect ourselves by catching SIGPIPE and clean
up the lockfiles as well in such a case.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I want directories of my working tree to be linked to from various
paths on my filesystem where third-party components expect them, both
in development and production environments. A build system's install
step could solve this, but I develop scripts and web pages that don't
need to be built. Git's submodule system could solve this, but we
tend to develop, branch, and test those directories all in unison, so
one big repository feels more natural. We prefer to edit and commit
on the symlinked paths, not the canonical ones, and in that setting,
"git pull" fails to find the top-level directory of the repository
while other commands work fine.
"git pull" fails because POSIX shells have a notion of current working
directory that is different from getcwd(). The shell stores this path
in PWD. As a result, "cd ../" can be interpreted differently in a
shell script than chdir("../") in a C program. The shell interprets
"../" by essentially stripping the last textual path component from
PWD, whereas C chdir() follows the ".." link in the current directory
on the filesystem. When PWD is a symlink, these are different
destinations. As a result, Git's C commands find the correct
top-level working tree, and shell scripts do not.
Changes:
* When interpreting a relative upward (../) path in cd_to_toplevel,
prepend the cwd without symlinks, given by /bin/pwd
* Add tests for cd_to_toplevel and "git pull" in a symlinked
directory that failed before this fix, plus contrasting scenarios
that already worked
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a merge that has a conflict was rebased, then rebase stopped to let
the user resolve the conflicts. However, thereafter --continue failed
because the author-script was not saved. (This is rebase -i's way to
preserve a commit's authorship.) This fixes it by doing taking the same
failure route after a merge that is also taken after a normal cherry-pick.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This extends t3409-rebase-preserve-merges by a case where the merge that
is rebased has a conflict. Therefore, the rebase stops and expects that
the user resolves the conflict. However, currently rebase --continue
fails because .git/rebase-merge/author-script is missing.
The test script had allocated two identical clones, but only one of them
(clone2) was used. Now we use both as indicated in the comment. Also,
two instances of && was missing in the setup part.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even though newer Porcelain tools always record the tagger information
when creating new tags, export/import pair should be able to faithfully
reproduce ancient tag objects that lack tagger information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
When no tagger was found (old Git produced tags like this),
no "tagger" line is printed (but this is incompatible with the current
git fast-import).
Alternatively, you can pass the option --fake-missing-tagger, forcing
fast-export to fake a tagger
Unspecified Tagger <no-tagger>
with a tag date of the beginning of (Unix) time in the case of a missing
tagger, so that fast-import is still able to import the result.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a test which checks that negated patterns such as "!foo.html" can
override previous patterns such as "*.html". This is documented
behaviour but had not been tested so far.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the packs are made using multiple threads, they are no longer identical
on the 4-core Xeon I tested on.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When merge-recursive wanted to create a new file in the work tree (either
as the final result, or a hint for reference purposes while delete/modify
conflicts), it unconditionally overwrote an untracked file in the working
tree. Be careful not to lose whatever the user has that is not tracked.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a file was removed in HEAD, but modified in MERGE_HEAD, recursive merge
will result in a "CONFLICT (delete/modify)". If the (now untracked) file
already exists and was not added to the index, it is overwritten with the
conflict resolution contents.
In similar situations (cf. test 2), the merge would abort with
"error: Untracked working tree 'file' would be overwritten by merge."
The same should happen in this case.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a tag points at a bad or nonexistent object, we should diagnose the
breakage and exit. An earlier commit 4f3dcc2 (Fix 'git show' on signed
tag of signed tag of commit, 2008-07-01) lost this check and made it
segfault instead; not good.
This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In dc871831(Only use GIT_CONFIG in "git config", not other programs),
GIT_CONFIG_LOCAL was rested in peace, in favor of not reading
/etc/gitconfig and $HOME/.gitconfig at all when GIT_CONFIG is set.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it easier to recover from a mistaken branch deletion by displaying the
sha1 of the branch's tip commit.
Update t3200 test to match the change in output.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When I tweaked the patch to use $SHELL_PATH instead of a hard-coded
"#!/bin/sh" to produce 3aa1f7c (diff: respect textconv in rewrite diffs,
2008-12-09), I screwed up. This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently we just skip rewrite diffs for binary files; this
patch makes an exception for files which will be textconv'd,
and actually performs the textconv before generating the
diff.
Conceptually, rewrite diffs should be in the exact same
format as the a non-rewrite diff, except that we refuse to
share any context. Thus it makes very little sense for "git
diff" to show a textconv'd diff, but for "git diff -B" to
show "Binary files differ".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current emit_rewrite_diff code always writes a text patch without
checking whether the content is binary. This means that if you end up with
a rewrite diff for a binary file, you get lots of raw binary goo in your
patch.
Instead, if we have binary files, then let's just skip emit_rewrite_diff
altogether. We will already have shown the "dissimilarity index" line, so
it is really about the diff contents. If binary diffs are turned off, the
"Binary files a/file and b/file differ" message should be the same in
either case. If we do have binary patches turned on, there isn't much
point in making a less-efficient binary patch that does a total rewrite;
no human is going to read it, and since binary patches don't apply with
any fuzz anyway, the result of application should be the same.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
find_parent_branch generates branch@rev type branches when one has to
look back through SVN history to properly get the history for a branch
copied from somewhere not already being tracked by git-svn. If in the
process of fetching this history, git-svn is interrupted, then when one
fetches again, it will use whatever was last fetched as the parent
commit and fail to fetch any more history which it didn't get to before
being terminated. This is especially troubling in that different
git-svn copies of the same SVN repository can end up with different
commit sha1s, incorrectly showing the history as divergent and
precluding easy collaboration using git push and fetch.
To fix this, when we initialise the Git::SVN object $gs to search for
and perhaps fetch history, we check if there are any commits in SVN in
the range between the current revision $gs is at, and the top revision
for which we were asked to fill history. If there are commits we're
missing in that range, we continue the fetch from the current revision
to the top, properly getting all history before using it as the parent
for the branch we're trying to create.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In insert_file() subroutine (which is used to insert HTML fragments as
custom header, footer, hometext (for projects list view), and per
project README.html (for summary view)) we used:
map(to_utf8, <$fd>);
This doesn't work, and other form has to be used:
map { to_utf8($_) } <$fd>;
Now with test for t9600 added, for $GIT_DIR/README.html.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to the message of commit 0fe7c1de16,
"git diff" with three or more trees expects the merged tree first followed by
the parents, in order. However, this command reversed the order of its
arguments, resulting in confusing diffs. A comment /* Again, the revs are all
reverse */ suggested there was a reason for this, but I can't figure out the
reason, so I removed the reversal of the arguments. Test case included.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
All other state files use dash in their names, not underscores.
Also, there is no reason to call this "extra". Drop it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These tests make sure that "git am" does not lose command line options
specified when it was started, after it is interrupted by a patch that
does not apply earlier in the series.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'branch' subcommand incorrectly had the svn-remote to use hardcoded
as 'svn', the default remote name. This meant that branches derived
from other svn-remotes would try to use the branch and tag configuration
for the 'svn' remote, potentially copying would-be branches to the wrong
place in SVN, into the branch namespace for another project.
Fix this by using the remote name extracted from the svn info for the
specified git ref. Add a testcase for this behaviour.
[jc: squashed in a fix to test from Michael J Gruber for older svn (1.4)]
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are printfs around that do not grok '\1', but need '\01'.
Discovered on AIX 4.3.x.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The patch that allows "git bisect skip" to be passed a range of
commits using the "<commit1>..<commit2>" notation is flawed because
it introduces a regression when it was passed a simple rev or commit.
"git bisect skip <commit>" doesn't work any more, because <commit>
is quoted but not properly unquoted.
This patch fixes that and add tests cases to better check when it is
passed commits and range of commits.
While at it, this patch also properly quotes the non range arguments
using the "sq" function.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
The loop picks elements from @ARGV one by one, sifts them into arguments
meant for format-patch and the script itself, and pushes them to @files
and @rev_list_opts arrays. Pick elements from @ARGV starting at the
beginning using shift, instead of at the end using pop, as push appends
them to the end of the array.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Writing a tree out of an index with an "intent to add" entry is blocked.
This implies that you cannot "git commit" from such a state; however you
can still do "git commit -a" or "git commit $that_path".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This uses the extended index flag mechanism introduced earlier to mark
the entries added to the index via "git add -N" with CE_INTENT_TO_ADD.
The logic to detect an "intent to add" entry for the purpose of allowing
"git rm --cached $path" is tightened to check not just for a staged empty
blob, but with the CE_INTENT_TO_ADD bit. This protects an empty blob that
was explicitly added and then modified in the work tree from being dropped
with this sequence:
$ >empty
$ git add empty
$ echo "non empty" >empty
$ git rm --cached empty
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The sed call used in compare_svn_head_with() uses the + quantifier, which
is not supported in the OSX version of sed. It is replaced by the
equivalent \{1,\}.
Signed-off-by: Marcel Koeppen <git-dev@marzelpan.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original intention of 72909be (Add diff-option --ext-diff, 2007-06-30)
was to optionally allow the use of external diff viewer in "git log"
family (while keeping them disabled by default). It exposed the "allow
external diff" bit to the UI, but forgot to adjust the "git diff" codepath
that was set up to always allow use of the external diff viewer.
Noticed by Nazri Ramliy; tests by René Scharfe squashed in.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The list extra_refs contains tags and the objects referenced by them,
so that they can be handled at the end. When a tag references a
commit, that commit is added to the list using the same name.
Also, the function handle_tags_and_duplicates() relies on the order
the items were added to extra_refs, so clearly we do not want to
use a sorted list here.
Noticed by Miklos Vajna.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Avoid passing cygwin pathnames to Perl. Some Perls have problems using them
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The -A option calls pack-objects with the --unpack-unreachable option so
that the unreachable objects in local packs are left in the local object
store loose. But if the -d option to repack was _not_ used, then these
unpacked loose objects are redundant and unnecessary.
Update tests in t7701.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano