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

From: Wincent Colaiuta <win@wincent.com>
Date: Apr 24, 2010, 16:59 UTC
Message-ID: <8B19818F-6578-420B-974D-28C9E3283FD4@wincent.com>
In-Reply-To: <20100424164247.GM3563@machine.or.cz>

El 24/04/2010, a las 18:42, Petr Baudis escribió:

Show 19 quoted lines

> On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:
>> El 24/04/2010, a las 11:40, Jakub Narebski escribió:
>>> I'd like for 'git commit -a' to *fail* if there are staged changes for
>>> tracked files, excluding added, removed and renamed files.
> 
> Thanks for this suggestion, this is exactly what I wanted to propose!
> +1 here.
> 
> I think this could even be made a default in some time, I don't see any
> useful workflows this could prevent and adding -f is trivial enough for
> those who really want to go forward.
> 
>> For me this is going to far. While we don't want to make it _easy_ for users to shoot themselves in the foot, neither do we want to make it difficult or impossible for them to get the tool to do things that _might_ be a mistake. And what's the risk here? Accidentally committing too much is not a destructive change, and can be easily undone.
> 
> 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.

Cheers, Wincent