Yes. I think git commit -a (another classic example of a "work sensibly" option that you nearly always want to add) is a good example of both your reasons – it made sense when the git UI was intended to be used by porcelains rather than people, and also one could argue that power users are more likely to take advantage of the ability to not commit everything in one go.(Though, on the other hand, I am enough of a git power user to constantly take advantage of partial committing, and even I still find I nearly always have to remember to add -a – to the point that on the occasions I don't want to commit everything, I still find my fingers have reflexively added the -a and then I wonder what went wrong...)
git commit -a
I have configured a `git ci` alias and occasionally use it incorrectly in exactly the way you describe :-) Typical failure mode is: prepare partial commit, then type `git ci -m ...`, swear, and spend twice as long unpicking the error.
Mmm. In fact I find myself thinking that since git commit -a modifies your index in a way that can wipe out carefully prepared stuff in it, you'd actually quite like it to have the side effect of leaving the prior index state somewhere easily recoverable, in cases where the index was modified.Perhaps a handy approach would be for it to generate a second commit consisting of exactly what it would have done if you hadn't said -a, and pointed an ephemeral ref at it similar to FETCH_HEAD. Then you could trivially recover from an accidental -a by saying git reset NO_THE_OTHER_ONE, or some such.
git reset NO_THE_OTHER_ONE
I have yet to find a way in which http://git-man-page-generator.lokaltog.net/ (and this (http://git-man-page-generator.lokaltog.net/#4cdbeecda0e1c6b21d841a6d7ca70d9f) is a particularly good one) differs significantly from reality.
I realised reading this that indeed I *never* use "git commit" (except for the special case of "git commit --amend" for tweaking commit messages after "git am" in one particular workflow), because pretty much all the time I use git via stgit...
I thought partial committing was great when I first saw it, a much better way for mortals to work, and only experts could make a change in the file system perfect first time and commit it in one go :)But yes, git is full of things like that where a "do it right" option is added later and people differ in which one they use most commonly. And also yes, it's what your fingers normally type, not what the unadorned command is...In fact, what I probably want actually is similar to "git commit -a", but shows the proposed changes without changing the index, and only proceeds if I hit return. I should script that...
Hmm. I git commit without -a all the time – I would certainly find it more annoying to have to turn it off than I do having to turn it on. But then I always do a git diff as the first thing when I intend to commit, and I follow up with git commit -a only if the diff already is exactly what I want to commit, which often is not the case.
Generally I make commits once I know I have completed a logical step in the evolution of the code, which generally means I am some way into the next step or the one after or even the one after that one before I am certain. Sometimes this is because I’m not sure what the steps even will be before I start. With trivial steps it can happen that I know beforehand exactly what the step will be, and then I do it, and then (after checking the diff!) I can just commit it – in which case I use -a. With any slightly larger task, I often find myself not knowing how to narrate the overall change as a series of patches until after completing (some part of) it. And I never make “here’s how far I got” commits – an atrocious style, as far as I am concerned (which someone once described as using the VCS as a landfill). (Well I do git commit -mwip -a at the end of a day to record my progress. Always followed by a git reset HEAD^ next time I pick up the branch, though.)
git commit -mwip -a
git reset HEAD^
The thing that’s so wonderful about Git in all this is how the index lets me decouple the boundaries of the hacking from the boundaries of the resulting commits. If -a were a “work sensibly” option, or even just the default, that would be a constant point of friction to me.
(This is rather different from the example with find | xargs, which no one ever wants to work like they do without the -print0 | -0 switches. (Obviously the problem is that at least find has other uses than being combined with xargs, for which -print0 is wrong. (Note that find has picked up an -exec variant where the command is terminated with a plus instead of a semicolon, for accumulating multiple arguments into a single invocation. So find subsumes the core functionality of xargs, and that issue goes away… at the cost of do-one-thing-well purity. (I assume you are well aware of this – but just in case…))))
find | xargs
-print0 | -0