Re: non-empty index with git commit -a

[Jeff King <peff@peff.net>]

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

> 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