Re: Reachability lists in git

From: Alan Stern <stern@rowland.harvard.edu>
Date: Nov 18, 2014, 21:37 UTC
Message-ID: <Pine.LNX.4.44L0.1411181634080.2918-100000@iolanthe.rowland.org>
In-Reply-To: <xmqq1tp0uru5.fsf@gitster.dls.corp.google.com>

On Tue, 18 Nov 2014, Junio C Hamano wrote:

Show 19 quoted lines

> Alan Stern <stern@rowland.harvard.edu> writes:
> 
> >> > No.  Here's a simple example:
> >> >
> >> >             Y
> >> >            /
> >> >           /
> >> >          X--B
> >> >
> >> > In this diagram, X = B^.  But B isn't reachable from either X or Y, 
> >> > whereas it is reachable from one of X's children (namely Y).
> > ...
> > Thus, if B introduced a bug, that bug would not be present in Y.  But Y 
> > might be better for testing than X, because Y might fix some other 
> > problems that are present in X.
> 
> The problem with that line of reasoning is that in real life there
> will be unbound number of Y's that forked from a point before
> somebody wrote B.  Which one among these Y's would you pick and why?

I don't know. But I would like to see what is available. I might even merge all those commits and test that (if there aren't any bad conflicts).

Show 5 quoted lines

> If Y has fixed another problem that is present in X and make it
> easier to test, Z, a direct descendant of Y (i.e. Z^1 = Y), may have
> fixed yet another problem that is unrelated to the problem B
> introduced and it may make the result even easier to test.  Where do
> you stop?

If Y is maximal among the comments that B isn't reachable from and Z^ = Y then, by definition, B _is_ reachable from Z. Therefore the bug introduced in B will be present in Z, unless it got fixed somewhere in between. Either way, Z is not a good candidate for testing whereas Y is.

Alan Stern