Re: merge-base: fully contaminate the well.

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 11, 2005, 05:36 UTC
Message-ID: <Pine.LNX.4.64.0511102125510.4627@g5.osdl.org>
In-Reply-To: <7vzmobuc00.fsf@assigned-by-dhcp.cox.net>

On Thu, 10 Nov 2005, Junio C Hamano wrote:

>
> The discussion on the list demonstrated a pathological case where
> an ancestor of a merge-base can be left interesting.  This commit
> introduces a postprocessing phase to fix it.

Hmm. I'd suggest only doing this for the (relatively unlikely) case of there being more than one merge-base..

You don't even have to be exact about it: just see if the result list is bigger than one. (ie "result->next != NULL"). Yeah, sometimes there are result commits that get turned UNINTERESTING after they are added to the result list, and your "contaminate" phase would be strictly not needed then, but that's already a pretty unusual case.

So the cheap test is to just say

	/* Do we have multiple results? */
	if (result->next)
		contaminate_well(result);

no?

Btw, I don't think your contamination logic is necessarily complete. We may not even have parsed some of the commits that end up being on that strange corner case. I think you catch the particular case you tried, but I think that in theory, with long chains of commits out of date order, you could be in the situation of having determined that everything was uninteresting before you even parsed enough to see the chain from one merge-base to another.

In fact, I think it would happen with your pathological example if it had just one more commit out-of-order in the E-D-C-B chain. But I didn't walk it through.

		Linus