Re: [RFC] git reflog show

From: Junio C Hamano <junkio@cox.net>
Date: Dec 24, 2006, 21:47 UTC
Message-ID: <7v1wmpq83g.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0612241333280.19693@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 5 quoted lines

> Yes, but if we have to read the reflog anyway to determine the logical 
> (local) parent, we can just as well read the message, and display it, too.
>
> What it buys us is that we do not duplicate efforts here, and we can 
> easily visualize the reflog in gitk, too.

I do not think you can sanely rewrite parenthood.

Think about this sequence

	$ git init-db; edit foo; git add foo
	$ git commit -m 'first'
	$ edit foo; git add foo
        $ git commit -m 'second'
        $ git reset --hard HEAD@{1}

At this point, the commits on the reflog are:

        $ git show-branch --reflog=3 HEAD
        ! [HEAD@{0}] first
         ! [HEAD@{1}] second
          ! [HEAD@{2}] first
        ---
         +  [HEAD@{1}] second
        +++ [HEAD@{0}] first

We are currently at the first commit, and its "rewritten" parent should point at the second commit (i.e. pretend HEAD@{1} is the parent of HEAD@{0}). The "rewritten" parent of the second commit should be HEAD@{2}, but that is actually the same first commit which is HEAD@{0}.

Also I highly doubt visualization based on parents information rewritten to match the reflog order is of _any_ use. By rewriting the parenthood, you are losing the topology and your visualization is no better than what "tac .git/logs/$ref" would give.

I do agree that reusing the message formattng and display code from the usual log machinery is desirable. I think you can hook that information somewhere in object->util (or a callback mechanism) and teach log display machinery to use it as a generic mechanism. That might make the existing code to insert "Subject: " for --pretty=format simpler, but I haven't looked.