Re: [PATCH] Fix fetch completeness assumptions

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Sep 15, 2005, 16:42 UTC
Message-ID: <Pine.LNX.4.63.0509151219590.23242@iabervon.org>
In-Reply-To: <7vd5naah1m.fsf@assigned-by-dhcp.cox.net>

On Thu, 15 Sep 2005, Junio C Hamano wrote:

Show 21 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > Don't assume that any commit we have is complete; assume that any ref
> > we have is complete.
> >
> > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> >
> > ---
> > Only lightly tested, but it seems to work. Marks all of the commits in 
> > refs, and their ancestors back as far as the date of the commit it's 
> > processing. If the commit it's processing is marked, it doesn't recurse 
> > into it.
> 
> First I thought you were using the date for the cutting-off
> decision and was going to object to the patch because of it, but
> re-reading the code made me realize that you are using date only
> to better the heuristics that limits how many commits reachable
> from existing refs we would tangle to see if the newly seen
> commit is reachable from our refs -- the logic looks correct.
> 
> The "complete" commit_list is a clever piece of code; I like it.

It's actually just the core loop of rev-list's original behavior. It's equivalent to putting the commit we're looking for in the list and popping the list until it comes back out, except that it saves a bit of list-fiddling. It's worth knowing that you can do rev-list (minus some of the features for human-readability) integrated into your program with just a couple of lines.

	-Daniel
*This .sig left intentionally blank*