Re: 'commit -a' safety

Dnia sobota 24. kwietnia 2010 18:42, Petr Baudis napisał:

On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:

quoted

El 24/04/2010, a las 11:40, Jakub Narebski escribió:

quoted

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?
 

quoted

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?
 

quoted

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