Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

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

From: Matthieu Moy <hidden>
Date: 2016-06-15 22:43:08

Johannes Schindelin [off-list ref] writes:
Hi,

On Sun, 6 May 2007, Matthieu Moy wrote:
quoted
[...]

% 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 ;-).
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help