Re: Separating "add path to index" from "update content in index"

From: Junio C Hamano <junkio@cox.net>
Date: Dec 22, 2006, 05:10 UTC
Message-ID: <7vfyb87bxg.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <87d56cirs8.wl%cworth@cworth.org>

Carl Worth <cworth@cworth.org> writes:

Show 6 quoted lines

> I complained about this when I first encountered git, and back then I
> said what I thought I wanted was "git diff HEAD" by default. I was
> totally wrong, since diff from the index is so obviously correct for
> resolving a conflict. Junio even responded to my complaints by
> providing a new "git status -v -a" but frankly I've never used
> it.

I guess my responding to whatever you said was wasted effort, and if you do not like "git add" this time, I should not be surprised. That's kind of sad ;-).

Jokes aside.

I do not remember who advocated for making "git status" the preview of "git commit" to happen. Was that also you? I wonder how many people use this form:

	git status -v path1 path2...

Because if even somebody who wanted to have "commit preview" in "git status" does not use it for that intended purpose, I think we can reuse the good command name for something more useful, such as "git explain".

> I'd really like "git diff" to be what I want more often.

Running diff with index is what I do almost all the time. I think "more often" is different from person to person, but if "git diff" says nothing on a file that I know I added (and you cannot argue you do not remember it was a new file here --- you know you added it and that is why you are complaining about not seeing it), I'd be happy that I did not accidentally edited it to munge what I added -- because I add a file only when it is in a presentable, good state, in a good enough shape to take a snapshot (not necessarily good enough to commit, though).

And it is not just limited to adding the contents of a path that happened to be told git for the first time. Adding the contents of a path that was known to git also happens only when it is in a presentable good state. So running "git diff" and not seeing what I added before is a GOOD THING.

Show 11 quoted lines

> So I suppose I could implement the "add path without updating content"
> I want by doing something like:
>
> 	mv file file.tmp
> 	touch file
> 	git update-index --add file
> 	mv file.tmp file
>
> There. That gives me the result I want without breaking any git
> internals, (since I'm just building a new operation on top of existing
> git primitives).

Sure, what you want is "git add --no-add newfile", and I can understand that mode of operation if you are always going to commit with "git commit -a". Maybe we can have a config variable that makes "commit -a" and "add --no-add" the default for these two commands, and we do not have to change anything else.

One minor detail I wonder about is what mode bits would you give to that placeholder entry.

Show 7 quoted lines

> I think the best would be:
>
> 	git update-index --all
>
> which would still allow room for:
>
> 	git add --all

Wasn't it you who said "all" is ambiguous (all known to git vs all in this directory)?