Re: A note on merging conflicts..

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jul 2, 2006, 21:42 UTC
Message-ID: <Pine.LNX.4.64.0607021715370.9789@iabervon.org>
In-Reply-To: <20060702113133.GA11529@lsrfire.ath.cx>

On Sun, 2 Jul 2006, Rene Scharfe wrote:

Show 16 quoted lines

> 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*