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

From: Jakub Narebski <jnareb@gmail.com>
Date: Apr 24, 2010, 09:40 UTC
Message-ID: <m3633hdw9u.fsf_-_@localhost.localdomain>
In-Reply-To: <20100422155806.GC4801@progeny.tock>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 5 quoted lines

> 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.

Show 7 quoted lines

> 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