Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> 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.
>> 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).
-
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