Re: [RFC] git reflog show

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 26, 2006, 16:14 UTC
Message-ID: <Pine.LNX.4.63.0612261654330.19693@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <7vwt4fj1cs.fsf@assigned-by-dhcp.cox.net>

Hi,

On Mon, 25 Dec 2006, Junio C Hamano wrote:

Show 14 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> Also I highly doubt visualization based on parents information rewritten 
> >> to match the reflog order is of _any_ use.  By rewriting the parenthood, 
> >> you are losing the topology and your visualization is no better than 
> >> what "tac .git/logs/$ref" would give.
> >
> > Okay, but if they are _not_ rewritten, we can reuse the log machinery to 
> > show the revisions in "upstream..master@{2.hours.ago}", but in the order 
> > they came into the local repository.
> 
> 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.

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

Show 5 quoted lines

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

Rather, I think about introducing a "get_parents(revs, commit)" function in revision.c, which takes reflog information rather than commit->parents if "--walk-reflogs" is passed to setup_revisions().

I hope to have a proof of concept later today.

Ciao, Dscho