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

[Nicolas Pitre <nico@fluxnic.net>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1577 bytes --]

On Sat, 24 Apr 2010, Petr Baudis wrote:

> On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:
> > El 24/04/2010, a las 11:40, Jakub Narebski escribió:
> > > I'd like for 'git commit -a' to *fail* if there are staged changes for
> > > tracked files, excluding added, removed and renamed files.
> 
> Thanks for this suggestion, this is exactly what I wanted to propose!
> +1 here.
> 
> I think this could even be made a default in some time, I don't see any
> useful workflows this could prevent and adding -f is trivial enough for
> those who really want to go forward.
> 
> > 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.
> 
> Have you ever done this mistake? If you have done some extensive index
> editing, it is actually a major PITA to restore, and can be even
> destructive if your index and working tree are too much out-of-sync
> (this does happen to me not so seldom while I also use -a a lot for
> trivial commits).

In that case the deficiency is in the fact that no reflog preserves the 
intermediate state of the index, not the fact that you might be allowed 
to do it.  Strictly speaking there is no intermediate ref to log, but a 
synthetic commit could be created for this case just like a stash but 
stored in the current branch's reflog.


Nicolas