"Philip Oakley" <philipoak...@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.
