Re: [RFC] git reflog show

> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

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