Re: git-rev-list: proper lazy reachability

From: Linus Torvalds <torvalds@osdl.org>
Date: May 31, 2005, 14:35 UTC
Message-ID: <Pine.LNX.4.58.0505310730010.1876@ppc970.osdl.org>
In-Reply-To: <2cfc4032050531005820979ca7@mail.gmail.com>

On Tue, 31 May 2005, Jon Seymour wrote:

Show 20 quoted lines

>
> On 5/31/05, Linus Torvalds <torvalds@osdl.org> wrote:
> > 
> > Somebody should probably take a look at my simplistic algorithm, since it
> > can probably be improved upon and/or fixed for corner-cases.
> 
> Seems reasonable, though I think that in a graph like this:
> 
>      A 
>   /  |  \ 
> B    C   D
> |  /   /
> E
> | \ 
> F G
> 
> and searching for git-rev-list A ^B it would actually be better to stop
> at E (printing A,B,C,D,E), rather than B because the contemporaneously
> parallel edits C and D and the common base E are relevant to evaluating
> B since they got merged with B into A from the common starting point E.

You're talking about something else - you worry about showing a graph, for example.

What git-rev-list A B does is literally for something like a "changelog" - what commits were added in A that weren't in B, and the list is A, C and D. Or, more commonly, used for something like

	git-rev-list HEAD v2.6.12-rc5 | git-diff-tree --stdin -v -p drivers/usb

which basically says "what changed since 2.6.12-rc5 in the drivers/usb tree"?

So in that situation, you really do _not_ want to see B and E, even if you'd need those two to make all the connections. Because you've seen B and E already (they were in v2.6.12-rc5), and if you're looking for a bug that didn't happen in that release, you really only want to see the new stuff.

		Linus