Re: non-empty index with git commit -a

[Jeff King <peff@peff.net>]

On Wed, Feb 16, 2011 at 01:46:01PM -0800, Junio C Hamano wrote:

> > Also it would be not as easy as reflogs - you would have either to save
> > copy of index, or create a tree out of it and save reference in reflog.
> 
> Also note that "Create a tree out of it" is not always a useful way to
> save the state of the index.  The "stash" shares the same issue, but you
> would need an equivalent of a tarball that consists of the index file
> (with conflicted state) and the files in the working tree that corresponds
> to index entries with conflicted states if you want to be useful for
> storing a state away in case you botch the conflict resolution you are
> attempting.

I had assumed it would be a reflog of trees (or more likely parentless
commits), just keeping track of useful states. But the usage there isn't
very intuitive. You can do "git show index@{5.minutes.ago}:foo.c >bar.c"
to recover the state of a file, or even "git read-tree index@{1}" to
get a whole state. And those would be enough for the basic "oops, I just
want to go back to where I was".

But probably you should be able to do a three-way merge with where you
are now, with the HEAD at the time of save as a pseudo-parent. IOW,
treat the index state as if you had committed it and put it on a reflog.
And in the case that you are at the same HEAD, then a merge collapses
into a "fast-forward" to the index state you were at (I put
"fast-forward" in quotes because we are obviously not interested in
moving HEAD to the pseudo-commit at all, but just what ends up in the
index).

I dunno. I haven't thought all that hard about it, so maybe there is a
more clever way of doing it. Certainly the porcelain support for "reset
to this index, but don't move my HEAD" is not good, nor for "merge this
index, but nevermind about recording anything about the commit".  They
are both conceptually easy to implement in terms of plumbing, but the
commands to run them are a little unintuitive.

-Peff