On Tue, 31 May 2005, Jon Seymour wrote: > > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Jun 01 00:34:57 2005
This archive was generated by hypermail 2.1.8 : 2005-06-01 00:34:58 EST