Re: [PATCH 1/2] diff --cached: do not report i-t-a entries as "new"
From: Junio C Hamano <hidden>
Date: 2016-06-15 23:04:09
Nguyễn Thái Ngọc Duy [off-list ref] writes:
quoted hunk
Paths marked by "git add -N" are simply a reminder to the user that these files should be staged. If the user does not stage any of them, "git commit" will not record them. Align the behavior of "diff --cached" and "git commit". The most prominent result of this patch is "git status" no longer reports i-t-a paths as "Changes to be committed". Signed-off-by: Nguyễn Thái Ngọc Duy <redacted> --- diff-lib.c | 2 ++ 1 file changed, 2 insertions(+)diff --git a/diff-lib.c b/diff-lib.c index a85c497..db0e6f8 100644 --- a/diff-lib.c +++ b/diff-lib.c@@ -400,6 +400,8 @@ static void do_oneway_diff(struct unpack_trees_options *o, * Something added to the tree? */ if (!tree) { + if (idx && (idx->ce_flags & CE_INTENT_TO_ADD)) + return; show_new_file(revs, idx, cached, match_missing); return; }
This hunk by itself feels like it is going in the right direction.
The HEAD does not have it, and even though there is idx, it merely
is an i-t-a entry.
Don't you need to special case the call to show_modified() at the
end of this function as well, though? idx is i-t-a, and tree has a
concrete object. Should it appear as if the path already exists in
the index, or should we pretend as if idx is not yet there?
For example, after this sequence:
$ git init
$ >void
$ git add void
$ git commit -m void
$ git rm --cached void
$ git add -N void
HEAD has "void" with an empty blob, the index has i-t-a. I am not
sure if we should say something about path "void" when asked:
$ git diff --cached
Perhaps something like this to cover that case?
/*
* Something removed from the tree?
*/
- if (!idx) {
+ if (!idx || (ix->ce_flags & CE_INTENT_TO_ADD)) {
diff_index_show_file(revs, "-", tree, tree->sha1, 1, tree->ce_mode, 0);
return;
}