Re: [PATCH] Do not call git-rev-list from git-fetch-pack

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 21, 2005, 20:25 UTC
Message-ID: <Pine.LNX.4.64.0510211618420.25300@iabervon.org>
In-Reply-To: <Pine.LNX.4.63.0510211111440.4950@wbgn013.biozentrum.uni-wuerzburg.de>

On Fri, 21 Oct 2005, Johannes Schindelin wrote:

Show 23 quoted lines

> Hi,
> 
> On Fri, 21 Oct 2005, Junio C Hamano wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > +	   Branch1 has 40 commits since it last merged with branch2,
> > > +	   and branch2 has 2 more commits since then.
> > > +
> > > +	   On the other end, branch1 is up-to-date, but branch2 is not.
> > > +	   When fetching branch1, the 40 commits get sent, the first
> > > +	   is acknowledged as common, and the local head of branch2
> > > +	   never gets sent.
> > > +
> > > +	   As a consequence, the whole history of branch2
> > > +	   (git-rev-list branch2 ^branch1) gets packed and transmitted.
> > 
> > Arrrgggggggh.  The description above captures the essense of the
> > problem very well, but faking dates and still popping by recency
> > looks like a really ugly hack to me.
> 
> It is ugly. But it is a good heuristic. And the code is simple, because I 
> could use the existing functions for inserting into a commit_list.

The existing functions aren't really very complicated. You could easily separate out the pop and the adding of parents, and go first through a list of tips and then through the date-sorted list of ancestors. And I think that separation would be useful for some changes Linus was making to rev-list recently.

	-Daniel
*This .sig left intentionally blank*