Re: [RFC] git reflog show

From: Junio C Hamano <junkio@cox.net>
Date: Dec 26, 2006, 23:50 UTC
Message-ID: <7vhcvicj32.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0612270006460.19693@wbgn013.biozentrum.uni-wuerzburg.de>

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

Show 14 quoted lines

>> 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.

Show 14 quoted lines

>> 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).