Re: [RFC] git reflog show

[Junio C Hamano <junkio@cox.net>]

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

>> 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.
>
> Okay, but if they are _not_ rewritten, we can reuse the log machinery to 
> show the revisions in "upstream..master@{2.hours.ago}", but in the order 
> they came into the local repository.

Shawn's code was about showing where the tip of the branch was,
and I think you are talking about something entirely different,
which I would address later.

A sensible way to reuse existing code to implement Shawn's one
is to add the revisions to rev.pending, and iterate over that
array like "git show" does.  This does not need to touch the
existing revision walking code at all.  The most valuable parts
of the revision walking code are about ancestry traversal and
history simplification with pathspec, neither of which makes
much sense to use when "walking" reflog.  Reflog walking might
want to use the filtering by commit_match() but then it is only
the matter of renaming the function to a bit more specific name
and exporting it.

You can largely reuse the display side of the code that way, and
I think you should be able to hook into the code without making
it too specific to the reflog (perhaps using object->util and/or
a callback) if you need to give extra information (e.g. comments
and commit information from the log).

But it _also_ makes sense to use reflog when the primary thing
we are interested in seeing is not how the tip jumped around,
but seeing how the branch acquired commits, which I think is
what you are suggesting.  What we would want to have is a sort
order different from the existing topo or date, which is "reflog
order".  While I think it makes sense, a naive implementation
would be somewhat expensive.  Instead of sorting topologically
at the end of prepare_revision_walk (you would need to limit the
list if you do this), for each commit, you binary search the
reflog entries to find the earliest one that is the ancestor of
the commit, and use the reflog entry's timestamp as the age of
the commit (it's the first time the branch saw that commit), and
sort commits using that.