Re: Reverting an uncommitted revert

From: Nicolas Pitre <nico@cam.org>
Date: May 20, 2009, 03:35 UTC
Message-ID: <alpine.LFD.2.00.0905192328310.3906@xanadu.home>
In-Reply-To: <20090520032139.GB10212@coredump.intra.peff.net>

On Tue, 19 May 2009, Jeff King wrote:

Show 26 quoted lines

> On Tue, May 19, 2009 at 11:10:14PM -0400, Nicolas Pitre wrote:
> 
> > > So here's the idea: What if Git, upon a revert change (or git reset --hard
> > > HEAD), "committed" the changes to be reverted and then did the revert with a
> > > 'git reset --hard HEAD^'?  The reverted files would be disconnected from a
> > > branch, but they would be available in the reflog to retrieve.
> > 
> > I think there is indeed some value in having a commit of the work 
> > directory dirty state automatically made before this state is discarded, 
> 
> Related to this, I have wondered if it might be useful to have an "index
> reflog". If I do something like this:
> 
>   $ git add foo
>   $ hack hack hack
>   $ git add foo
> 
> Then the first added state of "foo" is available in the object database,
> but it is not connected to the name "foo" in any way, which makes it
> much harder to find. If we had a reflog pointing to trees representing
> the index state after each change, then it would be simple (you could
> look at "INDEX@{1}:foo" or similar).
> 
> I don't know if the performance is an issue. We are writing an extra
> tree every time we touch the index, but in many cases you are already
> writing a blob.

Well... Actually I think having a reflog dedicated to discarded state would probably be a better idea. And...

Show 9 quoted lines

> > and stuff a reference to that commit in the HEAD reflog.  I think such a 
> > feature would need to be made configurable and active by default.
> 
> I'm not sure if putting it in the HEAD reflog is a good idea. The
> reflogs and what goes in them are very user-visible. Do users make the
> assumption that HEAD@{1} will be where they expect (e.g., because they
> just did a reset, they expect HEAD@{1} to be the prevoius commit, but
> with this patch it would actually be HEAD@{2}, with HEAD@{1} as the
> worktree pseudo-commit)?

Having a "trash" reflog would solve this unambiguously. That could also include your index example above. However, in the index case, I'd record a reflog entry only if you're about to discard a previously non committed entry. If you do:

	$ git add foo
	$ git add bar
	$ git commit
	$ hack hack hack
	$ git add foo

then in this case there is nothing to be lost hence no additional entry in the "trash" reflog.

Nicolas