Re: non-empty index with git commit -a

From: Jeff King <peff@peff.net>
Date: Feb 16, 2011, 19:36 UTC
Message-ID: <20110216193643.GB22045@sigill.intra.peff.net>
In-Reply-To: <7vpqqrke30.fsf@alter.siamese.dyndns.org>

On Wed, Feb 16, 2011 at 10:51:31AM -0800, Junio C Hamano wrote:

Show 9 quoted lines

> > OK, so how precious is it? :)
> 
> The world is not that black-and-white, but is full of different shades of
> gray.
> 
> If you made mistakes with a second "git add", you can "reset --mixed"
> everything away and restart from scratch.  The same thing can be said for
> a mistaken "git commit -a" that can be "reset HEAD^" (or --amend).  So
> there is not much difference at the technical level.

Sure. The problem there is that "scratch" may involve losing some work you did picking apart changes.

> I don't think this is primarily about "protecting the index".  It is more
> about making the user feel better.  Compared to a mistaken second "add", a
> mistaken "commit -a" feels like a lot heavier point-of-no-return.

I guess. I have very occasionally run into the second-add problem and wanted to be able to return to an earlier index state, but I admit it doesn't come up that much. I just see them as the same problem.

I think I am also a little turned off by the config option solution because it seems very un-git to me. Our usual approach is to give the user a lot of flexibility, let them shoot their own foot off, and then let them know that their intact foot is waiting in the reflog, ready to be sewn back on.

Yes, we try to limit uselessly destructive actions before they happen. But this is not one of those cases. The exact command set that is being listed as dangerous is also part of a very reasonable workflow. It just depends on what the user's intention was.

But as I said, I am not against a config option if it is such a common problem. I certainly would not turn it on. And I don't think it should be on by default.

-Peff