Currently, the hunk headers produced by 'diff -p' are customizable by
setting the diff.*.funcname option in the config file. The 'funcname' option
takes a basic regular expression. This functionality was designed using the
GNU regex library which, by default, allows using backslashed versions of
some extended regular expression operators, even in Basic Regular Expression
mode. For example, the following characters, when backslashed, are
interpreted according to the extended regular expression rules: ?, +, and |.
As such, the builtin funcname patterns were created using some extended
regular expression operators.
Other platforms which adhere more strictly to the POSIX spec do not
interpret the backslashed extended RE operators in Basic Regular Expression
mode. This causes the pattern matching for the builtin funcname patterns to
fail on those platforms.
Introduce a new option 'xfuncname' which uses extended regular expressions,
and advertise it _instead_ of funcname. Since most users are on GNU
platforms, the majority of funcname patterns are created and tested there.
Advertising only xfuncname should help to avoid the creation of non-portable
patterns which work with GNU regex but not elsewhere.
Additionally, the extended regular expressions may be less ugly and
complicated compared to the basic RE since many common special operators do
not need to be backslashed.
For example, the GNU Basic RE:
^[ ]*\\(\\(public\\|static\\).*\\)$
becomes the following Extended RE:
^[ ]*((public|static).*)$
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is currently no call to git_config at the start of cmd_archive.
When creating tar archives the core config is read as a side-effect of
reading the tar specific config, but this doesn't happen for zip
archives.
The consequence is that in a configuration with core.autocrlf set,
although files in a tar archive are created with crlf line endings,
files in a zip archive retain unix line endings.
Signed-off-by: Charles Bailey <charles@hashpling.org>
Acked-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apparently do_switch() tolerates the lack of escaping in less
funky branch names. For the really strange and scary ones, we
need to escape them properly. It strangely maintains compatible
with the existing handling of branch names with spaces and
exclamation marks.
Reported-by: m.skoric@web.de ($gmane/94677)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Not doing so caused the "Malformed network data" error when a directoy
was deleted and replaced with a copy from an older version.
Signed-off-by: Alec Berryman <alec@thened.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The object oriented version of File::Temp is a rather new incarnation it
seems. The File::Temp man page for v5.8.0 says "(NOT YET IMPLEMENTED)" in
the 'Objects' section. Instead of creating a file with a unique name in
the system TMPDIR, we can create our own temporary file with a static
name and use that instead.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk> on RHEL 3, Perl 5.8.0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some versions of perl complain when 'STDERR' is used as the third argument
in the 3-argument form of open(). Convert to the 2-argument form which is
described for duping STDERR in my second edition camel book.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk> on RHEL 3, Perl 5.8.0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes for 1.6.0.2
Use compatibility regex library for OSX/Darwin
git-svn: Fixes my() parameter list syntax error in pre-5.8 Perl
Git.pm: Use File::Temp->tempfile instead of ->new
t7501: always use test_cmp instead of diff
Conflicts:
Makefile
The standard libc regex library on OSX does not support alternation
in POSIX Basic Regular Expression mode. This breaks the diff.funcname
functionality on OSX.
To fix this, we use the GNU regex library which is already present in
the compat/ diretory for the MinGW port. However, simply adding compat/
to the COMPAT_CFLAGS variable causes a conflict between the system
fnmatch.h and the one present in compat/. To remedy this, move the
regex and fnmatch functionality to their own subdirectories in compat/
so they can be included seperately.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Tested-by: Mike Ralphson <mike@abacus.co.uk> (AIX)
Tested-by: Johannes Sixt <johannes.sixt@telecom.at> (MinGW)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This should make the output more readable (by default using diff -u)
when some tests fail.
Also changed the diff order from "current expected" to "expected
current".
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This changes "git-foo" to "git foo" when message strings in tests
name git subcommands.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also use "git hash-object" and "git rev-parse" without dash.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
OS X sed doesn't understand '\n' on the right side of a substitution.
Use a valid substitution character instead and use 'tr' to convert
those to a newline.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This replaces 'git-svn' with 'git svn' in the tests.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Subversion tests use too many "git-foo" form, so I am converting them
in two steps.
This first step replaces literal strings "remotes/git-svn" and "git-svn-id"
by introducing $remotes_git_svn and $git_svn_id constants defined as shell
variables. This will reduce the number of false hits from "git grep".
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apparently do_switch() tolerates the lack of escaping in less
funky branch names. For the really strange and scary ones, we
need to escape them properly. It strangely maintains compatible
with the existing handling of branch names with spaces and
exclamation marks.
Reported-by: m.skoric@web.de ($gmane/94677)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Once we committed the locked index, we should release the lockfile. In
most cases this is done automatically when the process ends, but this is
not true in this case.
[jc: with additional tests from Eric Raible]
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.bogomips.org/git-svn:
git-svn: set auto_props when renaming files
t9124: clean up chdir usage
git-svn: fix 'info' tests for unknown items
git-svn: match SVN 1.5 behaviour of info' on unknown item
git svn info: always quote URLs in 'info' output
git svn info: make info relative to the current directory
git svn info: tests: fix ptouch argument order in setup
git svn info: tests: use test_cmp instead of git-diff
git svn info: tests: do not use set -e
git svn info: tests: let 'init' test run with SVN 1.5
git svn: catch lack of upstream info for dcommit earlier
git-svn: check error code of send_txstream
git-svn: Send deltas during commits
git-svn: Introduce SVN::Git::Editor::_chg_file_get_blob
git-svn: extract base blob in generate_diff
Patch-by: Paul Talacko <gnuruandstuff@yahoo.co.uk>:
<http://article.gmane.org/gmane.comp.version-control.git/95006>
> Hello,
>
> There's an issue in git-svn as autoprops are not applied to
> renamed files, only to added files.
>
> This patch fixes the bug.
[ew: added test case]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Spawn subshells when running things in subdirectories instead of
chdir-ing to the path of an undefined variable, which is
confusing.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* maint:
Update draft release notes for 1.6.0.2
stash: refresh the index before deciding if the work tree is dirty
Mention the fact that 'git annotate' is only for backward compatibility.
"blame -c" should be compatible with "annotate"
git-gui: Fix diff parsing for lines starting with "--" or "++"
git-gui: Fix string escaping in po2msg.sh
git gui: show diffs with a minimum of 1 context line
git-gui: update all remaining translations to French.
git-gui: Update french translation
Tries to shorten the refname to a non-ambiguous name.
Szeder Gábor noticed that the git bash completion takes a
tremendous amount of time to strip leading components from
heads and tags refs (i.e. refs/heads, refs/tags, ...). He
proposed a new atom called 'refbasename' which removes at
most two leading components from the ref name.
I myself, proposed a more dynamic solution, which strips off
common leading components with the matched pattern.
But the current bash solution and both proposals suffer from
one mayor problem: ambiguous refs.
A ref is ambiguous, if it resolves to more than one full refs.
I.e. given the refs refs/heads/xyzzy and refs/tags/xyzzy. The
(short) ref xyzzy can point to both refs.
( Note: Its irrelevant whether the referenced objects are the
same or not. )
This proposal solves this by checking for ambiguity of the
shorten ref name.
The shortening is done with the same rules for resolving refs
but in the reverse order. The short name is checked if it
resolves to a different ref.
To continue the above example, the output would be like this:
heads/xyzzy
xyzzy
So, if you want just tags, xyzzy is not ambiguous, because it
will resolve to a tag. If you need the heads you get a also
a non-ambiguous short form of the ref.
To integrate this new format into the bash completion to get
only non-ambiguous refs is beyond the scope of this patch.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous tests all expected the results from SVN and Git to be
identical, and expected both to return success. This cannot be
guaranteed: SVN changed the message style between 1.4 and 1.5, and
in 1.5, sets a failure exit code.
Change the tests to verify that 'git svn info <item>' sets a failure
exit code, and that its output contains the file name. This should
hopefully catch all other errors.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Changes 'git svn info' to always URL-escape the 'URL' and 'Repository'
fields and --url output, like SVN (at least 1.5) does.
Note that reusing the escape_url() further down in Git::SVN::Ra is not
possible because it only triggers for http(s) URLs. I did not know
whether extending it to all schemes would break SVN access anywhere,
so I made a new one that quotes in all schemes.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Previously 'git svn info <path>' would always treat the <path> as
relative to the working directory root, with a default of ".". This
does not match the behaviour of 'svn info'. Prepend $(git rev-parse
--show-prefix) to the path used inside cmd_info to make it relative to
the current working directory.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
The arguments must be <gitwc-path> <svnwc-path>, otherwise it fails to
update the timestamps (without setting a failure exit code) and
results in bad test output later on.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-diff does not appear to return the correct exit values, and gives
a false success for more than half (!) of the tests due to the space
in "trash directory" which git-svn fails to encode.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
Exiting in the middle of a test confuses the test suite, which will
just say "FATAL: Unexpected exit with code 1" in response to a failed
test, instead of actually diagnosing failure and continuing with the
next test.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Eric Wong <normalperson@yhbt.net>
There is no reason to have a separate variable cmd_is_annotate;
OUTPUT_ANNOTATE_COMPAT option is supposed to produce the compatibility
output, and we should produce the same output even when the command was
not invoked as "annotate" but as "blame -c".
Noticed by Pasky.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/maint-log-grep:
log --author/--committer: really match only with name part
diff --cumulative is a sub-option of --dirstat
bash completion: Hide more plumbing commands
When we tried to find commits done by AUTHOR, the first implementation
tried to pattern match a line with "^author .*AUTHOR", which later was
enhanced to strip leading caret and look for "^author AUTHOR" when the
search pattern was anchored at the left end (i.e. --author="^AUTHOR").
This had a few problems:
* When looking for fixed strings (e.g. "git log -F --author=x --grep=y"),
the regexp internally used "^author .*x" would never match anything;
* To match at the end (e.g. "git log --author='google.com>$'"), the
generated regexp has to also match the trailing timestamp part the
commit header lines have. Also, in order to determine if the '$' at
the end means "match at the end of the line" or just a literal dollar
sign (probably backslash-quoted), we would need to parse the regexp
ourselves.
An earlier alternative tried to make sure that a line matches "^author "
(to limit by field name) and the user supplied pattern at the same time.
While it solved the -F problem by introducing a special override for
matching the "^author ", it did not solve the trailing timestamp nor tail
match problem. It also would have matched every commit if --author=author
was asked for, not because the author's email part had this string, but
because every commit header line that talks about the author begins with
that field name, regardleses of who wrote it.
Instead of piling more hacks on top of hacks, this rethinks the grep
machinery that is used to look for strings in the commit header, and makes
sure that (1) field name matches literally at the beginning of the line,
followed by a SP, and (2) the user supplied pattern is matched against the
remainder of the line, excluding the trailing timestamp data.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ho/dashless:
tests: use "git xyzzy" form (t7200 - t9001)
tests: use "git xyzzy" form (t7000 - t7199)
tests: use "git xyzzy" form (t3600 - t6999)
tests: use "git xyzzy" form (t0000 - t3599)
'git foo' program identifies itself without dash in die() messages
Start conforming code to "git subcmd" style
'git clone <repo> path/' (note the trailing slash) fails, because the
entire path is interpreted as leading directories. So when mkdir tries to
create the actual path, it already exists.
This makes sure trailing slashes are removed.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/filter-branch:
revision --simplify-merges: make it a no-op without pathspec
revision --simplify-merges: do not leave commits unprocessed
revision --simplify-merges: use decoration instead of commit->util field
Documentation: rev-list-options: move --simplify-merges documentation
filter-branch: use --simplify-merges
filter-branch: fix ref rewriting with --subdirectory-filter
filter-branch: Extend test to show rewriting bug
Topo-sort before --simplify-merges
revision traversal: show full history with merge simplification
revision.c: whitespace fix
* maint:
Makefile: add merge_recursive.h to LIB_H
Improve documentation for --dirstat diff option
Bring local clone's origin URL in line with that of a remote clone
Documentation: minor cleanup in a use case in 'git stash' manual
Documentation: fix disappeared lines in 'git stash' manpage
Documentation: fix reference to a for-each-ref option
Make sure the reason for the command failure is actually due to
the detection of SHA1 collision.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On a local clone, "git clone" would use the fully DWIMmed path as the origin
URL in the resulting repo. This was slightly inconsistent with the case of a
remote clone where the _given_ URL was used as the origin URL (because the
DWIMming was done remotely, and was therefore not available to "git clone").
This behaviour caused problems when cloning a local non-bare repo with
relative submodule URLs, because these submodule URLs would then be resolved
against the DWIMmed URL (e.g. "/repo/.git") instead of the given URL (e.g.
"/repo").
This patch teaches "git clone" to use the _given_ URL - instead of the
DWIMmed path - as the origin URL. This causes relative submodule URLs to be
resolved correctly, as long the _given_ URL indicates the correct directory
against which the submodule URLs should be resolved.
The patch also updates a testcase that contained the old-style origin URLs.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This new option does essentially the same thing as -m option when checking
unmerged paths out of the index, but it uses the specified style instead
of configured merge.conflictstyle.
Setting "merge.conflictstyle" to "diff3" is usually less useful than using
the default "merge" style, because the latter allows a conflict that
results by both sides changing the same region in a very similar way to
get simplified substancially by reducing the common lines. However, when
one side removed a group of lines (perhaps a function was moved to some
other file) while the other side modified it, the default "merge" style
does not give any clue as to why the hunk is left conflicting. You would
need the original to understand what is going on.
The recommended use would be not to set merge.conflictstyle variable so
that you would usually use the default "merge" style conflict, and when
the result in a path in a particular merge is too hard to understand, use
"git checkout --conflict=diff3 $path" to check it out with the original to
review what is going on.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'tac' is not available everywhere, so substitute the equivalent Perl
code 'print reverse <>'. Noticed by Brian Gernhardt.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds "--intent-to-add" option to "git add". This is to let the
system know that you will tell it the final contents to be staged later,
iow, just be aware of the presense of the path with the type of the blob
for now. It is implemented by staging an empty blob as the content.
With this sequence:
$ git reset --hard
$ edit newfile
$ git add -N newfile
$ edit newfile oldfile
$ git diff
the diff will show all changes relative to the current commit. Then you
can do:
$ git commit -a ;# commit everything
or
$ git commit oldfile ;# only oldfile, newfile not yet added
to pretend you are working with an index-free system like CVS.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the tracked contents have CRLF line endings, colored diff output
shows "^M" at the end of output lines, which is distracting, even though
the pager we use by default ("less") knows to hide them.
The problem is that "less" hides a carriage-return only at the end of the
line, immediately before a line feed. The colored diff output does not
take this into account, and emits four element sequence for each line:
- force this color;
- the line up to but not including the terminating line feed;
- reset color
- line feed.
By including the carriage return at the end of the line in the second
item, we are breaking the smart our pager has in order not to show "^M".
This can be fixed by changing the sequence to:
- force this color;
- the line up to but not including the terminating end-of-line;
- reset color
- end-of-line.
where end-of-line is either a single linefeed or a CRLF pair. When the
output is not colored, "force this color" and "reset color" sequences are
both empty, so we won't have this problem with or without this patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
gitattributes: -crlf is not binary
git-apply: Loosen "match_beginning" logic
Fix example in git-name-rev documentation
shell: do not play duplicated definition games to shrink the executable
Fix use of hardlinks in "make install"
pack-objects: Allow missing base objects when creating thin packs
This teaches git-checkout to recreate a merge out of unmerged
index entries while resolving conflicts.
With this patch, checking out an unmerged path from the index
now have the following possibilities:
* Without any option, an attempt to checkout an unmerged path
will atomically fail (i.e. no other cleanly-merged paths are
checked out either);
* With "-f", other cleanly-merged paths are checked out, and
unmerged paths are ignored;
* With "--ours" or "--theirs, the contents from the specified
stage is checked out;
* With "-m" (we should add "--merge" as synonym), the 3-way merge
is recreated from the staged object names and checked out.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/maint-checkout-fix:
checkout --ours/--theirs: allow checking out one side of a conflicting merge
checkout -f: allow ignoring unmerged paths when checking out of the index
checkout: do not check out unmerged higher stages randomly
This teaches "git merge-file" to honor merge.conflictstyle configuration
variable, whose value can be "merge" (default) or "diff3".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When showing conflicting merges, we traditionally followed RCS's merge
output format. The output shows:
<<<<<<<
postimage from one side;
=======
postimage of the other side; and
>>>>>>>
Some poeple find it easier to be able to understand what is going on when
they can view the common ancestor's version, which is used by "diff3 -m",
which shows:
<<<<<<<
postimage from one side;
|||||||
shared preimage;
=======
postimage of the other side; and
>>>>>>>
This is an initial step to bring that as an optional feature to git.
Only "git merge-file" has been converted, with "--diff3" option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This lets you to check out 'our' (or 'their') version of an
unmerged path out of the index while resolving conflicts.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier we made "git checkout $pathspec" to atomically refuse
the operation of $pathspec matched any path with unmerged
stages. This patch allows:
$ git checkout -f a b c
to ignore, instead of error out on, such unmerged paths. The
fix to prevent checkout of an unmerged path from random stages
is still there.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
During a conflicted merge when you have unmerged stages for a
path F in the index, if you said:
$ git checkout F
we rewrote F as many times as we have stages for it, and the
last one (typically "theirs") was left in the work tree, without
resolving the conflict.
This fixes it by noticing that a specified pathspec pattern
matches an unmerged path, and by erroring out.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even after a handfle attempts, match_beginning logic still has corner
cases:
1bf1a85 (apply: treat EOF as proper context., 2006-05-23)
65aadb9 (apply: force matching at the beginning., 2006-05-24)
4be6096 (apply --unidiff-zero: loosen sanity checks ..., 2006-09-17)
ee5a317 (Fix "git apply" to correctly enforce "match ..., 2008-04-06)
This is a tricky piece of code.
We still incorrectly enforce "match_beginning" for -U0 matches.
I noticed this while trying out an example sequence from Clemens Buchacher:
$ echo a >victim
$ git add victim
$ echo b >>victim
$ git diff -U0 >patch
$ cat patch
diff --git i/victim w/victim
index 7898192..422c2b7 100644
--- i/victim
+++ w/victim
@@ -1,0 +2 @@ a
+b
$ git apply --cached --unidiff-zero <patch
$ git show :victim
b
a
The change inserts a new line before the second line, but we insist it to
be applied at the beginning. As the result, the code refuses to apply it
at the original offset, and we end up adding the line at the beginning.
Updates to the test script are by Clemens Buchacher.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
--reverse did not interact well with --parents, as the included test
case shows: in a history like
A--B.
\ \
`C--M--D
the command
git rev-list --reverse --parents --full-history HEAD
erroneously lists D as having no parents at all. (Without --reverse,
it correctly lists M.)
This is caused by the machinery driving --reverse: it first grabs all
commits through the normal routines, then runs them through the same
routines again, effectively simplifying them twice.
Fix this by moving the --reverse one level up, into get_revision().
This way we can cleanly grab all commits via the normal calls, then
just pop them off the list one by one without interfering with
get_revision_internal().
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
tutorial: gentler illustration of Alice/Bob workflow using gitk
pretty=format: respect date format options
make git-shell paranoid about closed stdin/stdout/stderr
Document gitk --argscmd flag.
Fix '--dirstat' with cross-directory renaming
for-each-ref: Allow a trailing slash in the patterns
When running a command like:
git log --pretty=format:%ad --date=short
the date option was ignored. This patch causes it to use whatever
format was specified by --date (or by --relative-date, etc), just
as the non-user formats would do.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unless used with --cached or grepping on a tree, "git grep" will
search on working directory, so set up worktree properly
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes "git diff", "git diff-files" and "git diff-index" to work
correctly under worktree setup. Because diff* family works in many modes
and not all of them require worktree, Junio made a nice summary
(with a little modification from me):
* diff-files is about comparing with work tree, so it obviously needs a
work tree;
* diff-index also does, except "diff-index --cached" or "diff --cached TREE"
* no-index is about random files outside git context, so it obviously
doesn't need any work tree;
* comparing two (or more) trees doesn't;
* comparing two blobs doesn't;
* comparing a blob with a random file doesn't;
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When one good revision is not an ancestor of the bad revision, the
merge bases between the good and the bad revision should be checked
to make sure that they are also good revisions.
A previous patch takes care of that, but it may check the merge bases
more often than really needed. In fact the previous patch did not try
to optimize this as much as possible because it is not so simple. So
this is the purpose of this patch.
One may think that when all the merge bases have been checked then
we can save a flag, so that we don't need to check the merge bases
again during the bisect process.
The problem is that the user may choose to checkout and test
something completely different from what the bisect process
suggested. In this case we have to check the merge bases again,
because there may be new merge bases relevant to the bisect
process.
That's why, in this patch, when we detect that the user tested
something else than what the bisect process suggested, we remove
the flag that says that we don't need to check the merge bases
again.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch, "git bisect", when it was given some good revs that
are not ancestor of the bad rev, didn't check if the merge bases were
good. "git bisect" just supposed that the user knew what he was doing,
and that, when he said the revs were good, he knew that it meant that
all the revs in the history leading to the good revs were also
considered good.
But in pratice, the user may not know that a good rev is not an
ancestor of the bad rev, or he may not know/remember that all revs
leading to the good rev will be considered good. So he may give a good
rev that is a sibling, instead of an ancestor, of the bad rev, when in
fact there can be one rev becoming good in the branch of the good rev
(because the bug was already fixed there, for example) instead of one
rev becoming bad in the branch of the bad rev.
For example, if there is the following history:
A--B--C--D
\
E--F
and we launch "git bisect start D F" then only C and D would have been
considered as possible first bad commit before this patch. This could
invite user errors; F could be the commit that fixes the bug that exists
everywhere else.
The purpose of this patch is to detect when "git bisect" is passed
some good revs that are not ancestors of the bad rev, and then to first
ask the user to test the merge bases between the good and bad revs.
If the merge bases are good then all is fine, we can continue
bisecting. Otherwise, if one merge base is bad, it means that the
assumption that all revs leading to the good one are good too is
wrong and we error out. In the case where one merge base is skipped we
issue a warning and then continue bisecting anyway.
These checks will also catch the case where good and bad have been
mistaken. This means that we can remove the check that was done latter
on the output of "git rev-list --bisect-vars".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mv/merge-custom:
t7606: fix custom merge test
Fix "git-merge -s bogo" help text
Update .gitignore to ignore git-help
Builtin git-help.
builtin-help: always load_command_list() in cmd_help()
Add a second testcase for handling invalid strategies in git-merge
Add a new test for using a custom merge strategy
builtin-merge: allow using a custom strategy
builtin-help: make some internal functions available to other builtins
Conflicts:
help.c
Previously, running "git format-patch -U5" would cause the
low-level diff machinery to change the diff output format
from "not specified" to "patch". This meant that
format-patch thought we explicitly specified a diff output
format, and would not use the default format. The resulting
message lacked both the diffstat and the summary, as well as
the separating "---".
Now format-patch explicitly checks for this condition and
uses the default. That means that "git format-patch -p" will
now have the "-p" ignored.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, when testing if the filesystem allows tabs in
filenames, bash issues an error something like:
./t4016-diff-quote.sh: pathname with HT: No such file or directory
which is caused by the failure of the (stdout) redirection,
since the file cannot be created. In order to suppress the
error message, you must redirect stderr to /dev/null, *before*
the stdout redirection on the command-line.
Also, remove a redundant filesystem check from the begining of
the t3902-quoted.sh test and standardise the "test skipped"
message to 'say' on exit.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This has been broken in v1.6.0 due to the reorganization of
the revision option parsing code. The "-i" is completely
ignored, but works fine in "git log --grep -i".
What happens is that the code for "-i" looks for
revs->grep_filter; if it is NULL, we do nothing, since there
are no grep filters. But that is obviously not correct,
since we want it to influence the later --grep option. Doing
it the other way around works, since "-i" just impacts the
existing grep_filter option.
Instead, we now always initialize the grep_filter member and
just fill in options and patterns as we get them. This means
that we can no longer check grep_filter for NULL, but
instead must check the pattern list to see if we have any
actual patterns.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix git-diff to make it produce useful 3-way diffs for merge conflicts in
repositories with autocrlf enabled. Otherwise it always reports that the
whole file was changed, because it uses the contents from the working tree
without necessary conversion.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Custom merge strategy does not even kick in when the merge is truly
trivial. The test depended on the behaviour in the git-merge rewritten in
C that broke the trivial merge completely.
Make the test to work on a non-trivial merge to make sure the strategy
kicks in.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "trivial merge" codepath wants to optimize itself by making an
internal call to the read-tree machinery, but it does not read the index
before doing so, and the codepath is never exercised. Incidentally, this
failure to read the index upfront means that the safety to refuse doing
anything when the index is unmerged does not kick in, either.
These two problem are fixed by using read_cache_unmerged() that does read
the index before checking if it is unmerged at the beginning of
cmd_merge().
The primary logic of the merge, however, assumes that the process never
reads the index in-core, and the call to write_cache_as_tree() it makes
from write_tree_trivial() will always read from the on-disk index that is
prepared the strategy back-ends. This assumption is now broken by the
above fix. To fix this issue, we now call discard_cache() before calling
write_tree_trivial() when it wants to write the on-disk index as a tree.
When multiple strategies are tried, their results are evaluated by reading
the resulting index and inspecting it. The codepath needs to make a call
to read_cache() for each successful strategy, and for that to work, they
need to discard_cache() the one read by the previous round.
Also the "trivial merge" forgot that the current commit is one of the
parents of the resulting commit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is needed to fix verify-pack -v with multiple pack arguments.
Also, in theory, revindex data (if any) must be discarded whenever
reprepare_packed_git() is called. In practice this is hard to trigger
though.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code handles additionally "refs/remotes/<something>/name",
"remotes/<something>/name", and "refs/<namespace>/name".
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tag rewriting code used a 'sed' expression to substitute the new tag
name into the corresponding field of the annotated tag object. But this is
problematic if the tag name contains special characters. In particular,
if the tag name contained a slash, then the 'sed' expression had a syntax
error. We now protect against this by using 'printf' to assemble the
tag header.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sometimes you want to keep the trash directory, even if all tests
passed. For example, when extending tests, it comes it quite handy.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* kh/diff-tree:
Add test for diff-tree --stdin with two trees
Teach git diff-tree --stdin to diff trees
diff-tree: Note that the commit ID is printed with --stdin
Refactoring: Split up diff_tree_stdin
* cc/merge-base-many:
git-merge-octopus: use (merge-base A (merge B C D E...)) for stepwise merge
merge-base-many: add trivial tests based on the documentation
documentation: merge-base: explain "git merge-base" with more than 2 args
merge-base: teach "git merge-base" to drive underlying merge_bases_many()
