Junio C Hamano <gitster@xxxxxxxxx> writes: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> Intent-to-add entries are basically "I may want to commit these files >> later, but for now they are untracked". As such, when the user does "git >> reset --hard <tree>", which removes i-t-a entries from the index, i-t-a >> entries in worktree should be kept as untracked. > > Hmm, I can see that the control flow of "reset --hard" for an i-t-a > path does pass through this function, but it is not very obvious > to see how this will not negatively affect other uses of the > unpack-trees machinery (e.g. "checkout" and "merge", especially when > such a path needs to turn into a directory by getting removed). > Thinking about it more, I have to say that I do not agree with the basic premise of this patch. I-T-A is not "may want to commit, but they are untracked" at all. It is "I know I want to add, I just cannot yet decide the exact contents". That is why "git add -N newfile && git grep string" would find the string from newfile, and "git add -N newfile && git diff HEAD newfile" would show the addition. Sane people would expect that "git reset --hard HEAD" would behave as "git diff HEAD | git apply --index -R" when your index is fully merged, but this change will break the expectation. Earlier we changed "git commit" to pretend as if an I-T-A entry does not exist in "git add -N newfile && git commit", but I think that was a mistake that was caused by the same fuzzy thinking. 3f6d56de (commit: ignore intent-to-add entries instead of refusing, 2012-02-07) does talk about the use of "git add -N" in conjunction with "git status" and "git diff", but somehow nobody realized that it was introducing inconsistency in the semantics. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html