On Sun, 2 Jul 2006, Rene Scharfe wrote: > On Sat, Jul 01, 2006 at 07:45:33PM -0400, Daniel Barkalow wrote: > > That is: (this only has the logic portion, and it's against master, so it > > isn't actually a really working patch or anything; also, it doesn't handle > > "--not a...b" correctly, whatever that should mean) > > [concept patch snipped] > > You mean something like the patch below? It seems to work, but in my > unscientific tests it's significant slower than the version based on > get_merge_bases() (0.17s vs 0.05s for > "git-rev-list 89719209...262a6ef7 66ae0c77...ced9456a"). Did I do > something wrong? > > You had no mark_parents_left_right() in your patch. I added it because > otherwise it wouldn't remove any common commits. Was this supposed to > work some other way? I'd been assuming that there was something that would propagate flags to parents in general in add_parents_to_list(). Of course, that doesn't make sense for arbitrary flags. It might be better to handle it there, and avoid traversing parent lists twice. I'm surprised that it isn't faster than using get_merge_bases(); I'd expect it to be faster than the call to get_merge_bases(), let alone get_merge_bases() plus the processing of output candidates. It should be doing less work that get_merge_bases() ultimately does (since get_merge_bases() has to do the boundary calculation after doing practically everything that the left and right addition to revision.c does), so there's clearly something strange going on. -Daniel *This .sig left intentionally blank* - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html