Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 3059 bytes --]

On Thu, 30 Nov 2006 15:40:58 -0800 (PST), Linus Torvalds wrote:
> 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

But, wait a second. What if I do my typo fix to file-a in between that
"git add" and the "git commit". Why should "git commit" insist so
vehemently on committing the _old_ state of file-a while "git commit
file-a" so happily commits the _new_ state?

I'm really not seeing conceptual consistency to what "commit <files>"
does compared to "commit".

The "commit <files>" case is a special-case of "commit -a" while
"commit" is just plain different. See?

I do like the direction Nico is going with "git add" and his little
tutorial. I think the first part of that, (without the twists), could
make a very nice introduction to git.

The "twists" part though is quite a nightmare, and "twists on twists"
is something that should be left to B-grade screenwriters, not
technical writers, (nothing against Nico there---the stuff is really
confusing).

But dropping back to the old default for "git commit explicit/file"
really would only make things worse.

>  - "git commit" on its own:
>
>     This is for things where you prepared things earlier: notably a merge,
>     for example.

For "notably a merge", how often is this not equivalent to "commit -a"
in your view?

>     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.

Personally, I think I use --amend to change the tree of the last
commit as often as I change just the message. Regardless of the
relative frequency, I definitely use it often for both of those modes,
so both should be supported.

>  - "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.

As I mention above, this usage is exactly "commit -a" but restricted
to just a few paths. Why isn't it just as brain-damaged to take
contents from the working tree instead of the index here as in the
case of my "add; fix typo; commit" example?

>  - "git commit -a"
>
>    Sure, this is the common case, but just how painful is it to type those
>    extra few characters?

If we all agree it's the most common, then why isn't it the default?!
It's the right thing for after resolving a conflicted merge, (since
the working tree is where the user _first_ resolves things, before the
changes make it to the index), the command is consistent with the
behavior of "git commit explicit/file", and the existing "git commit"
behavior would still be available in the rare cases it's desired, (and
then, how painful would it be to type the few extra characters to ask
for that?).

I know, I know. I said I'd give up and yet I keep harping on this
stuff. I'm hopeless.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]