Re: non-empty index with git commit -a

[Jeff King <peff@peff.net>]

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

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