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

From: Jakub Narebski <[email-masked]>
Date: Sat, 24 Apr 2010 02:40:39 -0700 (PDT)

Jonathan Nieder <[email-masked]> writes:

> Starting out, I can see how it would be comforting to people if
> ‘git commit’ would default to -a behavior if they ignore the index.
> That is logically a different operation, though, so it would also send
> a wrong message and make it harder in the long run to get used to the
> interface.

I agree that making 'git commit' do 'git commit -a' if there are no
staged changes would be a bad change.

> Instead, I think it would be better to focus on making the error
> message more helpful.  Right now there is a screen full of status
> before the advice, which might make it easy to get scared before
> reading it.
>
> Here’s a very rough patch to suppress that screenful.  What do you
> think?

It's a pity that people didn't concentrate on this part: improving
error message...

On a bit unrelated note what I'd like to have is 'git commit -a'
(optional) safety against accidentally getting rid of staged changes.

I'd like for 'git commit -a' to *fail* if there are staged changes for
tracked files, excluding added, removed and renamed files.  If you
have some staged changes you would get an error message:

  $ git add tracked-file
  $ git commit -a
  fatal: There are staged changes to tracked files
  hint: To commit staged changes, use 'git commit'
  hint: To commit all changes, use 'git commit -f -a' 

Perhaps this behavior would be turned on only if some config option,
like commit.preserveIndex or something like that is set to true...
-- 
Jakub Narebski
Poland
ShadeHawk on #git