From: Daniel Barkalow Date: Thu, 15 Sep 2005 16:42:17 GMT Subject: Re: [PATCH] Fix fetch completeness assumptions Message-ID: In-Reply-To: <7vd5naah1m.fsf@assigned-by-dhcp.cox.net> On Thu, 15 Sep 2005, Junio C Hamano wrote: > Daniel Barkalow writes: > > > Don't assume that any commit we have is complete; assume that any ref > > we have is complete. > > > > Signed-off-by: Daniel Barkalow > > > > --- > > 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*