Re: [FAQ?] Rationale for git's way to manage the index

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: May 6, 2007, 17:34 UTC
Message-ID: <vpqk5vlamav.fsf@bauges.imag.fr>
In-Reply-To: <Pine.LNX.4.64.0705061851411.4015@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 17 quoted lines

> Hi,
>
> On Sun, 6 May 2007, Matthieu Moy wrote:
>
>> [...]
>>
>> % git satus -a
>> % git commit -a -m "..."
>> 
>> In the former case, I have more commands to type, and in the second
>> case, I loose part of the stat-cache benefit: If I run "git status -a"
>> twice, the second run will actually diff all the files touched since
>> the last run, since "git status -a" actually updated a temporary
>> index, and discarded it afterwards, so it doesn't update the stat
>> information in the index (while "git status" would have).
>
> Have you tried "git status" _without_ "-a"?

Reading my message (including the last 5 words of the sentence you're quoting) would have told you that ;-).

>> In both cases, I can't really see the benefit.
>
> The benefit is a clear distinguishing between DWIM and low level. The 
> index contains _exactly_ what you told it to contain.

In other systems, commit commits _exactly_ the content of files on disk. And most people seem happy with that.

> By forcing users to use "-a" with "git commit",

Does this mean that the normal way to use "commit" is to use "-a"?

> you make it clear that a separate update steo is involved,

Well, with those kind of arguments, I could have my web browser not do DNS resolution for me, because it would make it clear that a separate step from HTTP request is involved. Still, this low-level thing brings no benefit to the user, and I know no web browser forcing the user to make this distinction.

> and if you made an error (which you see from the file list), you can
> abort, and start over with the original index.

You don't necessarily see your error from the file list:

% vi foo.c
% git add foo.c
% vi foo.c
% git commit -m foo
[...]
 create mode 100644 foo.c
%

This commited the old content of foo.c, while I hardly see any scenario where this is the expected behavior.

Then, being able to repare the error if I made it is interesting, but I don't get the reason why the error could not just be avoided.

Well, indeed, I just found a thread talking about this:

  http://lists-archives.org/git/196050-making-git-commit-to-mean-git-commit-a.html

I'll go through it, I might understand better after that ;-).

Thanks,

-- 
Matthieu