Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> On Mon, 13 Feb 2017, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>>
>> > That is why I taught the Git for Windows CI job that tests the four
>> > upstream Git integration branches to *also* bisect test breakages and
>> > then upload comments to the identified commit on GitHub
>>
>> Good. I do not think it is useful to try 'pu' as an aggregate and
>> expect it to always build and work [*1*], but your "bisect and
>> pinpoint" approach makes it useful to identify individual topic that
>> brings in a breakage.
>
> Sadly the many different merge bases[*1*] between `next` and `pu` (which
> are the obvious good/bad points for bisecting automatically) bring my
> build agents to its knees. I may have to disable the bisecting feature as
> a consequence.
Probably a less resource intensive approach is to find the tips of
the topics not in 'next' but in 'pu' and test them. That would give
you which topic(s) are problematic, which is a better starting point
than "Oh, 'pu' does not build". After identifying which branch is
problematic, bisection of individual topic would be of more manageable
size.
$ git log --first-parent --oneline 'pu^{/^### match next}..pu'
will you the merges of topics left outside 'next'. I often reorder
to make the ones that look more OK than others closer to the bottom,
and if the breakages caused by them are caught earlier than they hit
'next', that would be ideal.
This is one of these times I wish "git bisect --first-parent" were
available. The above "log" gives me 27 merges right now, which
should be bisectable within 5 rounds to identify a single broken
topic (if there is only one breakage, that is).