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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 25, 2016 at 6:23 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> 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.

We can agree to disagree. To me i-t-a is still a reminder, not a real
tracked entry (with unknown content).

> 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.

$ echo abc >abc
$ git add -N abc
$ git diff HEAD|LANG=C git apply --index -R
error: abc: does not match index
$ cat abc
abc

OK this is just nit-picking. We could probably make it work, though
I'm not interested in doing that.

> 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.
-- 
Duy
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]