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

From: Wincent Colaiuta <win@wincent.com>
Date: Apr 24, 2010, 11:10 UTC
Message-ID: <AC853FF9-6723-4824-BB2C-E7E8F79AA95E@wincent.com>
In-Reply-To: <m3633hdw9u.fsf_-_@localhost.localdomain>

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

Show 19 quoted lines

> 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