Re: a few remaining issues...

["Shawn O. Pearce" <spearce@spearce.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 9 Jan 2007, Junio C Hamano wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > On Fri, 5 Jan 2007, Shawn O. Pearce wrote:
> > >
> > >> I myself am also severly lacking in time right now.
> > >
> > > Did you have any chance to look at the patch I posted?

No, I had not had a chance to look at it.  I don't see the patch in
my inbox currently, so I must have deleted it earlier.  As much as
I want this feature in 1.5.0's final release I don't really have
the time/inclination to dredge though my own local mailing list
archives or through the online ones to locate it either.

Right now I want to track down a nasty bug in git-http-fetch that I
noticed recently that's keeping me from tracking git.git through an
HTTP proxy, and then I need to do some hacking on this lightweight
subproject implementation I'm working on.  None of the existing
implementations do what I needed over two weeks ago, so I'm writing
my own.  I really need it to be done before the end of the week.

> > > It adds 
> > > "--walk-reflogs" option to the revision walker, and as long as there is 
> > > reflog information, traverses the commits in that order. It also shows the 
> > > reflog data just below the "commit" line.
> > 
> > What does it do when you say, for example:
> > 
> > 	git log --walk-reflogs master..next
> 
> It means that (ideally) all revisions are shown which are in the reflog 
> chain of next, and _not_ in the reflog chain of master.

That makes a lot of sense actually.  Cute feature.
 
> However, once the reflog traversal hits the oldest reflog entry, it 
> reverts to commit parent traversal.

That doesn't make sense...

> > I couldn't make heads or tails out of the patch and did not understand 
> > what it was trying to do.  It looked as if you were making the log 
> > traversal machinery to walk _both_ reflog (probably from the latest to 
> > older) and the usual ancestry.
> 
> Yes, first reflog, then usual ancestry.
> 
> Would you want that changed to _only_ reflog traversal?

Yes.  The old ancestry has nothing to do with my local reflog.  I
want to know where my reflog ends, as there's no record of that
branch's lifespan before that point.

Right now I have a reflog on `pu` which I've had since reflogs were
first introduced last summer.  Yet it only goes back to Dec 23, 2006.
Looking at the old ancestry of pu back into last Oct isn't really
interesting when I'm studying what changes happened to locally.

-- 
Shawn.