On Wed, 20 May 2009, Jeff King wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html