user/sven/git.git/diff-lib.c, branch v2.6.1

Merge branch 'nd/diff-i-t-a'

2015-06-25T17:47:46Z

* nd/diff-i-t-a: Revert "diff-lib.c: adjust position of i-t-a entries in diff"

Revert "diff-lib.c: adjust position of i-t-a entries in diff"

2015-06-23T17:37:21Z

This reverts commit d95d728aba06a34394d15466045cbdabdada58a2. It turns out that many other commands that need to interact with the result of running diff-files and diff-index, e.g. "git apply", "git rm", etc., need to be adjusted to the new world order it brings in. For example, it would break this sequence to correct a whitespace breakage in the parts you changed: git add -N file git diff --cached file | git apply --cached --whitespace=fix git checkout file In the old world order, "diff" showed a patch to modify an existing empty file by adding its full contents, and "apply" updated the index by modifying the existing empty blob (which is what an Intent-to-Add entry records in the index) with that patch. In the new world order, "diff" shows a patch to create a new file with its full contents, but because "apply" thinks that the i-t-a entry already exists in the index, it refused to accept a creation. Adjusting "apply" to this new world order is easy, but we need to assess the extent of the damage to the rest of the system the new world order brought in before going forward and adjust them all, after which we can resurrect the commit being reverted here. Signed-off-by: Junio C Hamano

Merge branch 'nd/diff-i-t-a'

2015-05-19T20:17:49Z

After "git add -N", the path appeared in output of "git diff HEAD" and "git diff --cached HEAD", leading "git status" to classify it as "Changes to be committed". Such a path, however, is not yet to be scheduled to be committed. "git diff" showed the change to the path as modification, not as a "new file", in the header of its output. Treat such paths as "yet to be added to the index but Git already know about them"; "git diff HEAD" and "git diff --cached HEAD" should not talk about them, and "git diff" should show them as new files yet to be added to the index. * nd/diff-i-t-a: diff-lib.c: adjust position of i-t-a entries in diff

Merge branch 'bc/object-id'

2015-05-06T04:00:23Z

Identify parts of the code that knows that we use SHA-1 hash to name our objects too much, and use (1) symbolic constants instead of hardcoded 20 as byte count and/or (2) use struct object_id instead of unsigned char [20] for object names. * bc/object-id: apply: convert threeway_stage to object_id patch-id: convert to use struct object_id commit: convert parts to struct object_id diff: convert struct combine_diff_path to object_id bulk-checkin.c: convert to use struct object_id zip: use GIT_SHA1_HEXSZ for trailers archive.c: convert to use struct object_id bisect.c: convert leaf functions to use struct object_id define utility functions for object IDs define a structure for object IDs

diff-lib.c: adjust position of i-t-a entries in diff

2015-03-23T20:42:33Z

Entries added by "git add -N" are reminder for the user so that they don't forget to add them before committing. These entries appear in the index even though they are not real. Their presence in the index leads to a confusing "git status" like this: On branch master Changes to be committed: new file: foo Changes not staged for commit: modified: foo If you do a "git commit", "foo" will not be included even though "status" reports it as "to be committed". This patch changes the output to become On branch master Changes not staged for commit: new file: foo no changes added to commit The two hunks in diff-lib.c adjust "diff-index" and "diff-files" so that i-t-a entries appear as new files in diff-files and nothing in diff-index. Due to this change, diff-files may start to report "new files" for the first time. "add -u" needs to be told about this or it will die in denial, screaming "new files can't exist! Reality is wrong." Luckily, it's the only one among run_diff_files() callers that needs fixing. Now in the new world order, a hierarchy in the index that contain i-t-a paths is written out as a tree object as if these i-t-a entries do not exist, and comparing the index with such a tree object that would result from writing out the hierarchy will result in no difference. Update a test in t2203 that expected the i-t-a entries to appear as "added to the index" in the comparison to instead expect no output. An earlier change eec3e7e4 (cache-tree: invalidate i-t-a paths after generating trees, 2012-12-16) becomes an unnecessary pessimization in the new world order---a cache-tree in the index that corresponds to a hierarchy with i-t-a paths can now be marked as valid and record the object name of the tree that results from writing a tree object out of that hierarchy, as it will compare equal to that tree. Reverting the commit is left for the future, though, as it is purely a performance issue and no longer affects correctness. Helped-by: Michael J Gruber Helped-by: Junio C Hamano Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

diff: convert struct combine_diff_path to object_id

2015-03-14T05:43:13Z

Also, convert a constant to GIT_SHA1_HEXSZ. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

run_diff_files(): clarify computation of sha1 validity

2015-02-04T22:27:01Z

Remove the need to have duplicated "if there is a change then feed null_sha1 and otherwise sha1 from the cache entry" for the "new" side of the diff by introducing two temporary variables to point at the object name of the old and the new side of the blobs. Signed-off-by: Junio C Hamano

Merge branch 'jk/diff-files-assume-unchanged'

2014-06-16T17:06:12Z

* jk/diff-files-assume-unchanged: run_diff_files: do not look at uninitialized stat data

run_diff_files: do not look at uninitialized stat data

2014-05-15T16:35:33Z

If we try to diff an index entry marked CE_VALID (because it was marked with --assume-unchanged), we do not bother even running stat() on the file to see if it was removed. This started long ago with 540e694 (Prevent diff machinery from examining assume-unchanged entries on worktree, 2009-08-11). However, the subsequent code may look at our "struct stat" and expect to find actual data; currently it will find whatever cruft was left on the stack. This can cause problems in two situations: 1. We call match_stat_with_submodule with the stat data, so a submodule may be erroneously marked as changed. 2. If --find-copies-harder is in effect, we pass all entries, even unchanged ones, to diff_change, so it can list them as rename/copy sources. Since we found no change, we assume that function will realize it and not actually display any diff output. However, we end up feeding it a bogus mode, leading it to sometimes claim there was a mode change. We can fix both by splitting the CE_VALID and regular code paths, and making sure only to look at the stat information in the latter. Furthermore, we push the declaration of our "struct stat" down into the code paths that actually set it, so we cannot accidentally access it uninitialized in future code. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jc/hold-diff-remove-q-synonym-for-no-deletion'

2014-03-07T23:17:41Z

Remove a confusing and deprecated "-q" option from "git diff-files"; "git diff-files --diff-filter=d" can be used instead.