Hi,
On Tue, 26 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>
> >> 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.
>
> [...]
>
> 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.
> >> 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.
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.
So I tend to think that rewriting the parents, buffer _and_ flags is the
way to go.
Ciao,
Dscho
-
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