From: "Christian Couder" <christian.couder@xxxxxxxxx>
On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano <gitster@xxxxxxxxx>
wrote:
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.
Yeah, this is a bug in the bisect algorithm. Fixing it is in the GSoC
2017 Ideas.
There are also a few ideas at the SO answers:
http://stackoverflow.com/a/5652323/717355
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.
It is still probably more resource intensive than it couls be.
[...]
This is one of these times I wish "git bisect --first-parent" were
available.
Implementing "git bisect --first-parent" is also part of the GSoC 2017
Ideas.
By the way it should not be very difficult as a patch to do this and
more was proposed a long time ago:
https://public-inbox.org/git/4D3CDDF9.6080405@xxxxxxxxx/
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).
--
Philip