Re: 'commit -a' safety

On Sat, 24 Apr 2010, Nicolas Pitre wrote:

On Sat, 24 Apr 2010, Jakub Narebski wrote:

quoted

First, this is to be optional safety, by default turned off.  So if you
do not have problems with situation where you accidentally use 
'git commit -a' instead of 'git commit', committing not what you wanted
and prepared, you simply do not turn it on.

In which case it is worthless.  No one will turn this feature on if they 
don't fully understand what it entails, and those who do understand it 
are probably not the people who would actually benefit from it.

One would turn it after losing carefully prepared index by running 
"git commit -a" when one meant "git commit" ;-)

More seriously, it could be made default if it is not too annoying.

quoted

Second, to be more exact the safety would be triggered only if staged
change _differs_ from what is in working area.  Therefore

  $ git add file
  $ git commit -a

would not trigger this safety, while

  $ git add file
  $ edit file
  $ git commit -a
  fatal: There are staged changes

would trigger it.

Much better yet would be a warning at the top of the summary message in 
the commit text editor.  This way you won't introduce an incompatible 
and potentially annoying behavior that no one is likely to opt-in for, 
and the warning will give a hint that you might be losing some 
intermediate state if you don't abort the commit.

As Petr Baudis said, this actually work *if* you use editor to generate
commit message, and you have chance to see commit message template.
Also the information was considered not visible enought, hence patch
at the beginning of the series.

-- 
Jakub Narebski
Poland