Re: [RFC] git reflog show

Johannes Schindelin [off-list ref] writes:

quoted

I am not proposing to introduce a new object type here, but
conceptually we could.  Maybe a quick hack would be to represent
each reflog entry as a phony "struct commit" in core,

 1. whose tree is taken from the tree of the tip commit,

 2. whose buffer is handcrafted by the true commit log message
    with data from reflog, and

 3. whose parent list points at another phony "commit" that
    represents ref@{N+1} reflog entry.

I see only one problem with this approach: "next..master@{0}" would stop 
to work as expected.

I was not talking about doing this as part of the usual
"rev-list".  This is a special hack to support reflog, and that
is Ok, because reflog is a very special hack itself.  I was
trying to rephrase what you said about reusing revision
traversal machinery for walking reflog.  The actual syntax would
more likely to be:

	reflog show master@{20}..master@{4} -- paths...

where you do NOT even allow handle_revision_arg() to interpret
double-dots, nor sha1_hex() to interpret master@{20}.  We do not
want the real commit objects when walking reflog entries.

You are going to synthesize an imaginary commit ancestry chain
that corresponds to the reflog entries of 'master' branch (so
you would error out when your replacement handle_revision_arg()
finds either is not a reflog entry and/or talk about different
refs).

In other words, the usual "next..master@{0}" WILL not do this
phony wrapping with "imaginary reflog objects".  We know it
cannot work.

quoted

I think I misunderstood your proposal and the misunderstanding resulted 
in an unrelated useful enhancement ;-).  If HEAD@{0} and HEAD@{2} points 
at the same commit, then obviously commits reachable from that commit 
did not come into the branch no later than HEAD@{2} time (what HEAD@{0} 
says becomes irrelevant), so you can define an order that lists commits 
in the order the earliest time they appeared on a branch.

I fear that this traversal is not as easy as it seems. We cannot just 
blindly walk the reflogs, since the simplification relies on being able to 
actually rewrite the commit_list. Also, if a commit was seen, it must be 
possible to show it _again_. And if you show the commit diff, you rely on 
commit->parents actually containing the rewritten parents. And the same 
commit could be in revs->commits twice, and the correct reflog has still 
to be shown.

I think you are misunderstanding me completely.  This part is
about a separate topic of using reflog when walking the real
history.  We do not wrap or do anything funky like that.  We
just walk the true history.  We do not walk reflog at all.

Then, before you output anything, at the point you would call
topological sort, instead you would sort the commits with the
timestamp of the earliest appearance in the repository (or on
a particular branch), instead of the usual commit date.  And
reflog data is how you would determine when each commit appeared
in this repository (or on this particular branch).