Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.
>
> If I read Shawn's mail correctly, it is not only about the tip.
What I meant was that I did not see anything that mentions
"$ref@{ago}~47" and such; what was shown was only about the
transition between the tip.
>> 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.
>
> Sorry to be a PITA here, but I think that it _would_ make sense. Quite
> often I ask myself "That feature in this file used to work. When and how
> was it changed?" Right now, I use git-log with path simplification, but
> with reflog walking, I could ask in a more specific way!
When you put it that way, it sort of makes sense. Right now,
get_revision() walks the chain of commits using the parent links
and the history simplification (try_to_simplify_commit) looks at
each commit and compares the tree with its parents' trees to
decide if the commit is worth considering.
If we _had_ an object type "reflog entry" which has one "parent
reflog entry" field and an associated "tip commit" object, just
like a commit object has zero or more "parent commit" field and
an associated "tree" object, the same algorithm could be taught
to follow the "parent reflog entry" chain while walking and look
at the tree associated with "tip commit" for the history
simplification purposes.
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.
Then we would give a new populate_parent() member to "struct
revinfo" which is called instead of parse_object() to fill the
commit's parent list before traversal. With 1. we do not have
to touch any code for history simplification, with 2. we do not
have to touch pretty-print-commit (the result would include
whatever reflog wants to add in the message automatically), and
with 3. plus populate_parent callback would give us the
traversal.
>> 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".
>
> I think it should not be a different sort order. As you pointed out
> yourself, a "git reset --hard HEAD^" removes the assumption of the commit
> list being a DAG.
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.
-
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