Junio C Hamano <junkio@xxxxxxx> wrote: > 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). So what you are proposing is to make the reflog visible in 'git log' by a new option? Or to just try to reuse all of its display code but keep the reflog under 'git reflog show' ? -- Shawn. - 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