Re: [git-for-windows] Re: Continuous Testing of Git on Windows

["Philip Oakley" <philipoakley@iee.org>]

[sorry for the repeated emails - I'd prepared it off line, and then suffered 
a number of auto send actions]
From: "Junio C Hamano" <gitster@pobox.com>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> In the next..pu case the abstraction is in the other direction, we
>> have potentially multiple points of infection (from feature branches),
>> and a broad test (the whole test suite). In this case I believe we
>> would like to investigate initially the --first-parent line with a
>> classic bisect for the first point of failure (obviously including
>> feature branch merges). This would identify which feature merge, or
>> regular commit, created the first breakage.
>
> If you are going first-parent, you would limit the bisection to a
> single-strand-of-pearls, and I agree that it is a good strategy to
> find which topic branch merge broke the tip of 'pu'.
>
> If we assume that there is no funny interaction among topics that
> cancel a breakage brought in by one topic with another breakage by
> another topic, then no matter how many broken topics there are, I
> agree that we would get to the first broken topic.
>

> A good thing that comes once we assume that topics are more-or-less
> independent is that we could rebuild 'pu' minus the broken topic
> identified by the above procedure and repeat it to find other broken
> topics, still using the --first-parent bisection, because master..pu
> is a linear sequence of merges of individual topics.
>

For an integrator, or especially a CI tool, simply checking the second 
parents of each topic merge (post fail) should at least indicate if the 
basics of the feature actually passed the tests, though it doesn't check for 
interaction issues. This could give direct author feedback!
--
Philip