[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@xxxxxxxxx>
"Philip Oakley" <philipoakley@xxxxxxx> 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