Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)

> El 24/04/2010, a las 18:42, Petr Baudis escribió:
> 
> > Have you ever done this mistake? If you have done some extensive index
> > editing, it is actually a major PITA to restore, and can be even
> > destructive if your index and working tree are too much out-of-sync
> > (this does happen to me not so seldom while I also use -a a lot for
> > trivial commits).
> 
> Yes I have occasionally committed more than I meant to, but rarely much more, and almost never due to using "git commit -a", seeing as I hardly ever use it. I am of the "commit early and often" school, and my most common pattern is committing tiny batches of changes which I review frequently with "git diff" and then again by staging them with "git add --patch" (aliased as "git patch" seeing as I use it so often).

> >> IMO, the fact that the commit message editor is populated with a list of changed files that will be included in the commit is enough for people to see what's actually going to happen.
> > 
> > BTW, I almost always use -m instead of the commit editor. ;-)
> 
> Are you not a big fan of "subject line + justification" commit message format? Consider it one of the perks of using the format: your editor will show you a nice summary that gives you yet another chance to double-check what you're about to commit.