On Tue, Jun 7, 2016 at 3:42 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > >> +--shift-ita:: >> + By default entries added by "git add -N" appear as an existing >> + empty file in "git diff" and a new file in "git diff --cached". >> + This option makes the entry appear as a new file in "git diff" >> + and non-existent in "git diff --cached". > > I do not think this should exist at the UI level, I need it. I do "git diff --stat" and "git diff --cached --stat" a lot more often than "git status". Without this option, I'm stuck with the old behavior. > even though the > use of it in wt-status.c (below) makes a very good sense at least > as a temporary band-aid. > > At the philosophical level, I however think this "I-T-A does not > logically exist in the index (yet)" is a mistake, and "an option > controls if I-T-A does or does not exist depending on who calls it" > is even worse; it is a road to insanity. i-t-a entries have dual personality (perhaps because it's implemented as an index entry). Although I think the "does not exist" aspect will win in most cases. The intention behind the revert is we have more time to examine case by case and gradually convert them. Maybe in the end one behavior wins and we no longer need another. A thought of keeping i-t-a entries in an index extension instead crossed my mind. It may simplify things a bit (e.g. there's no "ghost" entries any more and active_nr in 3/4 can remain "the number of _real_ entries"). The few parts that do need to know about i-t-a entries need explict modification (probably git-reset and git-diff). But I don't know yet if it would just lead to another nightmare. > For example, because I-T-A does not logically exist in the index, > "git reset --hard" should not remove it but make it untracked again > (but I do not think it does). After "git add -N foo", because "foo" > does not exist in the index, "git clean" should remove it for the > definition of what's in the index to be logically consistent, but > the whole intent of "add -N" is that the user meant it is worth > checking into sometime in the future, which contradicts with its > removal upon "clean". I think we should fix them. I started that and so far only 4d55200 (grep: make it clear i-t-a entries are ignored - 2015-12-27) has made it to 'master'. > So, I dunno. I just remembered why the old behavior (abort to commit if i-t-a entries are present) bugged me: it does not work well with splitting changes in worktree into multiple commits (e.g. with "git add -p"). Even though I want git remind me to commit an i-t-a entry in the end, it does not necessarily mean I have to do it in the next commit, which may cover a bunch of files except that i-t-a file. I don't see any way around that except ignoring i-t-a entries at commit time. If there's another way, I'm all ears. -- 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