Re: A note on merging conflicts..

On Sun, 2 Jul 2006, Rene Scharfe wrote:

On Sat, Jul 01, 2006 at 07:45:33PM -0400, Daniel Barkalow wrote:

quoted

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*