Re: Reverting an uncommitted revert

From: Nicolas Pitre <nico@cam.org>
Date: May 20, 2009, 18:04 UTC
Message-ID: <alpine.LFD.2.00.0905201358000.3906@xanadu.home>
In-Reply-To: <20090520165854.GA23031@coredump.intra.peff.net>

On Wed, 20 May 2009, Jeff King wrote:

Show 22 quoted lines

> On Wed, May 20, 2009 at 06:13:55PM +0200, Sverre Rabbelier wrote:
> 
> > On that note, the usefulness of such a feature is dependant on the
> > support we have for actually restoring an entry from this new reflog.
> > The current reflog is so amazingly useful because git has
> > awesome-cherry-pick-and-the-like-commit-handling powers that make it
> > easy to restore the otherwise lost state. But as far as I know,
> > there's no nice 'n easy support for restoring state to the information
> > contained in this new reflog, is there?
> 
> I was envisioning a reflog of tree objects, so you could do:
> 
>   $ git reflog show TRASH ;# show the reflog message
>   $ git show TRASH@{1} ;# show what's in the tree
>   $ git show TRASH@{1}:path/to/file ;# see a file
>   $ git checkout TRASH@{1} path/to/file ;# restore a file
> 
> which should all work as-is.
> 
> I suspect "git log -g" might need some tweaking to get a tree rather
> than a commit (but in theory we should just show the "Reflog *:" headers
> and not the commit headers).

Even simpler (for the user) would be to create a full commit with a synthetic message. The advantage is that the commit would have for parent the HEAD commit at the moment the operation leading to the reflog entry was made, with the date tag, etc. The message could even contain information about what exactly was discarded by the operation. This commit would be referenced only by the trash reflog and not be part of any branch. And all your examples above should still work of course.

Nicolas