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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 14, 2017, 21:08 UTC
Message-ID: <xmqqd1ek8oqo.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1702142150220.3496@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 17 quoted lines

> On Mon, 13 Feb 2017, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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).