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:
pgpgIixd6lyoY.pgp
Description: PGP signature