delta/git.git/tree-diff.c, branch fc/git-version-gen

pathspec: support :(literal) syntax for noglob pathspec

2013-07-15T17:56:09+00:00

Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano

tree-diff: remove the use of pathspec's raw[] in follow-rename codepath

2013-07-15T17:56:09+00:00

Put a checkpoint to guard unsupported pathspec features in future.

Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano

remove init_pathspec() in favor of parse_pathspec()

2013-07-15T17:56:09+00:00

While at there, move free_pathspec() to pathspec.c

Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano

remove diff_tree_{setup,release}_paths

2013-07-15T17:56:09+00:00

Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano

guard against new pathspec magic in pathspec matching code

2013-07-15T17:56:07+00:00

GUARD_PATHSPEC() marks pathspec-sensitive code, basically all those
that touch anything in 'struct pathspec' except fields "nr" and
"original". GUARD_PATHSPEC() is not supposed to fail. It's mainly to
help the designers catch unsupported codepaths.

Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano

parse_pathspec: add special flag for max_depth feature

2013-07-15T17:56:06+00:00

match_pathspec_depth() and tree_entry_interesting() check max_depth
field in order to support "git grep --max-depth". The feature
activation is tied to "recursive" field, which led to some unwanted
activation, e.g. 5c8eeb8 (diff-index: enable recursive pathspec
matching in unpack_trees - 2012-01-15).

This patch decouples the activation from "recursive" field, puts it in
"magic" field instead. This makes sure that only "git grep" can
activate this feature. And because parse_pathspec knows when the
feature is not used, it does not need to sort pathspec (required for
max_depth to work correctly). A small win for non-grep cases.

Even though a new magic flag is introduced, no magic syntax is. The
magic can be only enabled by parse_pathspec() caller. We might someday
want to support ":(maxdepth:10)src." It all depends on actual use
cases.

max_depth feature cannot be enabled via init_pathspec() anymore. But
that's ok because init_pathspec() is on its way to /dev/null.

Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano

Merge branch 'jk/maint-null-in-trees'

2012-08-27T18:54:28+00:00

We do not want a link to 0{40} object stored anywhere in our objects.

* jk/maint-null-in-trees:
  fsck: detect null sha1 in tree entries
  do not write null sha1s to on-disk index
  diff: do not use null sha1 as a sentinel value

diff_setup_done(): return void

2012-08-03T19:11:07+00:00

diff_setup_done() has historically returned an error code, but lost
the last nonzero return in 943d5b7 (allow diff.renamelimit to be set
regardless of -M/-C, 2006-08-09).  The callers were in a pretty
confused state: some actually checked for the return code, and some
did not.

Let it return void, and patch all callers to take this into account.
This conveniently also gets rid of a handful of different(!) error
messages that could never be triggered anyway.

Note that the function can still die().

Signed-off-by: Thomas Rast 
Signed-off-by: Junio C Hamano

diff: do not use null sha1 as a sentinel value

2012-07-29T22:04:32+00:00

The diff code represents paths using the diff_filespec
struct. This struct has a sha1 to represent the sha1 of the
content at that path, as well as a sha1_valid member which
indicates whether its sha1 field is actually useful. If
sha1_valid is not true, then the filespec represents a
working tree file (e.g., for the no-index case, or for when
the index is not up-to-date).

The diff_filespec is only used internally, though. At the
interfaces to the diff subsystem, callers feed the sha1
directly, and we create a diff_filespec from it. It's at
that point that we look at the sha1 and decide whether it is
valid or not; callers may pass the null sha1 as a sentinel
value to indicate that it is not.

We should not typically see the null sha1 coming from any
other source (e.g., in the index itself, or from a tree).
However, a corrupt tree might have a null sha1, which would
cause "diff --patch" to accidentally diff the working tree
version of a file instead of treating it as a blob.

This patch extends the edges of the diff interface to accept
a "sha1_valid" flag whenever we accept a sha1, and to use
that flag when creating a filespec. In some cases, this
means passing the flag through several layers, making the
code change larger than would be desirable.

One alternative would be to simply die() upon seeing
corrupted trees with null sha1s. However, this fix more
directly addresses the problem (while bogus sha1s in a tree
are probably a bad thing, it is really the sentinel
confusion sending us down the wrong code path that is what
makes it devastating). And it means that git is more capable
of examining and debugging these corrupted trees. For
example, you can still "diff --raw" such a tree to find out
when the bogus entry was introduced; you just cannot do a
"--patch" diff (just as you could not with any other
corrupted tree, as we do not have any content to diff).

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

use custom rename score during --follow

2011-12-16T20:33:49+00:00

If you provide a custom rename score on the command line,
like:

  git log -M50 --follow foo.c

it is completely ignored, and there is no way to --follow
with a looser rename score. Instead, let's use the same
rename score that will be used for generating diffs. This is
convenient, and mirrors what we do with the break-score.

You can see an example of it being useful in git.git:

  $ git log --oneline --summary --follow \
	    Documentation/technical/api-string-list.txt
  86d4b52 string-list: Add API to remove an item from an unsorted list
  1d2f80f string_list: Fix argument order for string_list_append
  e242148 string-list: add unsorted_string_list_lookup()
  0dda1d1 Fix two leftovers from path_list->string_list
  c455c87 Rename path_list to string_list
   create mode 100644 Documentation/technical/api-string-list.txt

  $ git log --oneline --summary -M40 --follow \
	  Documentation/technical/api-string-list.txt
  86d4b52 string-list: Add API to remove an item from an unsorted list
  1d2f80f string_list: Fix argument order for string_list_append
  e242148 string-list: add unsorted_string_list_lookup()
  0dda1d1 Fix two leftovers from path_list->string_list
  c455c87 Rename path_list to string_list
   rename Documentation/technical/{api-path-list.txt => api-string-list.txt} (47%)
  328a475 path-list documentation: document all functions and data structures
  530e741 Start preparing the API documents.
   create mode 100644 Documentation/technical/api-path-list.txt

You could have two separate rename scores, one for following
and one for diff. But almost nobody is going to want that,
and it would just be unnecessarily confusing. Besides which,
we re-use the diff results from try_to_follow_renames for
the actual diff output, which means having them as separate
scores is actively wrong. E.g., with the current code, you
get:

  $ git log --oneline --diff-filter=R --name-status \
            -M90 --follow git.spec.in
  27dedf0 GIT 0.99.9j aka 1.0rc3
  R084    git-core.spec.in        git.spec.in
  f85639c Rename the RPM from "git" to "git-core"
  R098    git.spec.in     git-core.spec.in

The first one should not be considered a rename by the -M
score we gave, but we print it anyway, since we blindly
re-use the diff information from the follow (which uses the
default score). So this could also be considered simply a
bug-fix, as with the current code "-M" is completely ignored
when using "--follow".

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano