user/sven/git.git/diff-lib.c, branch v1.8.0.2

diff: do not use null sha1 as a sentinel value

2012-07-29T22:04:32Z

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

diff-index: enable recursive pathspec matching in unpack_trees

2012-01-16T22:17:18Z

The pathspec structure has a few bits of data to drive various operation modes after we unified the pathspec matching logic in various codepaths. For example, max_depth field is there so that "git grep" can limit the output for files found in limited depth of tree traversal. Also in order to show just the surface level differences in "git diff-tree", recursive field stops us from descending into deeper level of the tree structure when it is set to false, and this also affects pathspec matching when we have wildcards in the pathspec. The diff-index has always wanted the recursive behaviour, and wanted to match pathspecs without any depth limit. But we forgot to do so when we updated tree_entry_interesting() logic to unify the pathspec matching logic. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'cn/eradicate-working-copy'

2011-10-05T19:36:26Z

* cn/eradicate-working-copy: Remove 'working copy' from the documentation and C code

Merge branch 'jc/diff-index-unpack'

2011-10-05T19:35:53Z

* jc/diff-index-unpack: diff-index: pass pathspec down to unpack-trees machinery unpack-trees: allow pruning with pathspec traverse_trees(): allow pruning with pathspec

Remove 'working copy' from the documentation and C code

2011-09-21T21:26:38Z

The git term is 'working tree', so replace the most public references to 'working copy'. Signed-off-by: Carlos Martín Nieto Signed-off-by: Junio C Hamano

diff-index: pass pathspec down to unpack-trees machinery

2011-08-29T22:09:17Z

And finally, pass the pathspec down through unpack_trees() to traverse_trees() callchain. Before and after applying this series, looking for changes in the kernel repository with a fairly narrow pathspec becomes somewhat faster. (without patch) $ /usr/bin/time git diff --raw v2.6.27 -- net/ipv6 >/dev/null 0.48user 0.05system 0:00.53elapsed 100%CPU (0avgtext+0avgdata 163296maxresident)k 0inputs+952outputs (0major+11163minor)pagefaults 0swaps (with patch) $ /usr/bin/time git diff --raw v2.6.27 -- net/ipv6 >/dev/null 0.01user 0.00system 0:00.02elapsed 104%CPU (0avgtext+0avgdata 43856maxresident)k 0inputs+24outputs (0major+3688minor)pagefaults 0swaps Signed-off-by: Junio C Hamano

Merge branch 'jc/diff-index-refactor'

2011-08-08T19:33:33Z

* jc/diff-index-refactor: diff-lib: refactor run_diff_index() and do_diff_cache() diff-lib: simplify do_diff_cache()

Merge branch 'jc/maint-reset-unmerged-path'

2011-08-01T22:00:08Z

* jc/maint-reset-unmerged-path: reset [] paths...: do not mishandle unmerged paths

diff-lib: refactor run_diff_index() and do_diff_cache()

2011-07-14T04:58:21Z

The latter is meant to be an API for internal callers that want to inspect the resulting diff-queue, while the former is an implementation of "git diff-index" command. Extract the common logic into a single helper function and make them thin wrappers around it. Signed-off-by: Junio C Hamano

diff-lib: simplify do_diff_cache()

2011-07-14T04:58:15Z

Since 34110cd (Make 'unpack_trees()' have a separate source and destination index, 2008-03-06), we can run unpack_trees() without munging the index at all, but do_diff_cache() tried ever so carefully to work around the old behaviour of the function. We can just tell unpack_trees() not to touch the original index and there is no need to clean-up whatever the previous round has done. Signed-off-by: Junio C Hamano