On Thu, 30 Nov 2006, Junio C Hamano wrote:
>
> I sense that you are inviting me to argue for reverting the
> other "git commit" braindead which is spelled "--only" (and
> worse yet, it is the default). I am very tempted.
I actually really like the current defaults for "git commit".
And I say that despite the fact that the defaults are _different_ from the
original ones.
I like the fact that when you do "git commit filename", it really will
commit _only_ that file, not the other files you added. It's logical.
So you can do
echo a > file-a
echo b > file-b
git add file-a file-b
git commit file-a
and it will only commit one of them. Now, admittedly, the status message
that you get is slightly misleading (it says that "file-b" is untracked,
which is not strictly true or at least somewhat confusing - it's untracked
only within the context of that one commit), but this is all logically
consistent.
And it's wonderful for noticing "Oh, sh*t, I forgot to commit that
previous change, let's commit that other file first!". You can do things
like this _despite_ the fact that you've added other files to the list of
files to be committed.
The current semantics for "git commit" are really powerful, and really
flexible. Yes, there are different "cases", but they all have their place:
- "git commit" on its own:
This is for things where you prepared things earlier: notably a merge,
for example. But it might be the "--amend" case too, where you simply
don't want to change any of the working tree, just the commit message.
The fact that it has a nice fallback for the "nothing to commit" case
which basically just prints out the same thing as "git status" is just
gravy.
- "git commit explicit/file anotherfile"
This is great (and I use it) exactly for when you have random other
additions in your tree that are brewing, and you just want to commit a
particular fix that takes precedence. You may be in the middle of
something else, but you found a critical bug that needs to be fixed,
and while you _could_ do it on another branch, it's just a lot more
convenient to specify exactly what you want to commit.
- "git commit -a"
Sure, this is the common case, but just how painful is it to type those
extra few characters? And not defaulting to this is just sensible,
considering that "-a" really is not _that_ special, and the above two
cases simply aren't that unusual either. And it's just good to make
people have to _think_ about the fact that it commits everything that
have dirty.
At least for me, it turns out that the only mode I _never_ use personally
is the "git commit -i" thing, which was actually the original behaviour,
and which you'd think that I would encourage for that reason. But no. Of
all the modes of "git commit", that's the one I think is the least
important, and least interesting.
Of course, during a merge, you do need "-i" if you list files, but I think
"-a" subsumes almost all cases (you _can_ use "-i file-list" or totally
manually decide to have some extra edits you did that you don't want to
commit together with the merge, but that's such a special case that I
doubt anybody does it, so I don't think it's a big deal).
Anyway, we have "-i", and we don't force anybody to use it, so the fact
that it's a bit odd and not that useful doesn't really matter. It
certainly "fits" in the git commit family as another case, it's just not
one of the important cases.
Linus
-
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