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

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

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

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.

Where do we stop here with the hand-holding? Would you also want a fatal error here?:

$ git add foo
$ git commit -- bar
fatal: There are staged changes to tracked files

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.

Cheers,
Wincent