Re: [RFC] git reflog show

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

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.