Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 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.
-
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