Re: non-empty index with git commit -a

From: Jeff King <peff@peff.net>
Date: Feb 16, 2011, 19:48 UTC
Message-ID: <20110216194855.GC22045@sigill.intra.peff.net>
In-Reply-To: <vpqbp2cmfy6.fsf@bauges.imag.fr>

On Wed, Feb 16, 2011 at 11:28:17AM +0100, Matthieu Moy wrote:

Show 8 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > So? Your question was whether index state is precious. If it's precious,
> > shouldn't we be keeping a history of it?
> 
> If it's really precious, it probably means you should be commit
> --amend instead. You'd get the reflog, and essentially the same
> functionalities.

Yeah, that is good advice, and I do actually end up doing a lot of intermediate commits and then either amending or sorting them out at the end. And that helps with sorting out big changes.

But it does sort of feel like saying "we don't need a safety valve. You just need to back up your work before doing anything dangerous". I have to remember to do it. Which is fine if my workflow is add-amend-add-amend. But maybe I have some half-saved index state and I am about to try doing a merge checkout or stash apply.

Anyway, I'm not convinced it is all that precious (at least not enough to merit working on the reflog). Yes, there have been times I've wished I could go back to the index state of a minute ago, and had to re-sort changes. But it usually doesn't take all that much time (thanks to "git add -p"). My main objection is that I just don't see those cases as different from "git commit -a". Either it is worth protecting, or it isn't.

-Peff