Re: 'commit -a' safety

[Jakub Narebski <jnareb@gmail.com>]

Dnia sobota 24. kwietnia 2010 18:42, Petr Baudis napisał:
> 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.

Isn't it how (most of) backwards incompatibile changes are made, first
adding an option for new behaviour, then later (optionally) changing
the default?
 
>> 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).

That is the situation this *optional* safety is meant to protect against:
when somebody sometimes use "git add" + "git commit", but sometimes
use "git commit -a", to protect carefully index against accidental
"git commit -a" instead of "git commit".

Is it worth additional code complication?  Shoult it be turned on by
default?  Does it promote unsafe workflow of committing untested changes?
 
>> 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. ;-)

So restructuring commit message template so the information is more
visible in the case of accidental "git commit -a" wouldn't always help...

-- 
Jakub Narebski
Poland