Re: [PATCH] unpack-trees: do not delete i-t-a entries in worktree even when forced

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> 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.