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

Hi Philip,

On Tue, 14 Feb 2017, Philip Oakley wrote:

From: "Christian Couder" <redacted>

quoted

On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano [off-list ref]
wrote:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

On Mon, 13 Feb 2017, Junio C Hamano wrote:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

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

Thanks for that link!

However, my main aim was not to get distracted into yet another corner of
Git that needs to be fixed (I am on enough of those projects already).

I was merely surprised (and not in a good way) that a plenty ordinary
bisect between `next` and `pu` all of a sudden tested a *one year old*
commit whether it was good or not.

And I doubt that the strategy to mark all second parents of all merge
commits in pu..next as "good" would work well, as the merge bases *still*
would have to be tested.

I guess what I have to resort to is this: if I know that `next` tests
fine, and that `pu` fails, I shall mark all merge bases as "good". I am
sure this has its own set of pitfalls, undoubtedly costing me more time on
that front...

But at least my cursory analysis of this idea seems to make sense: I use
`next` essentially as a catch-all to verify that the breakage has entered
`pu`, but not yet `next`. This reasoning makes sense, given that we know
the waterfall topology of pu/next/master/maint: patches enter from left to
right, i.e. anything that entered `pu` may later enter `next`, but not
vice versa.

Ciao,
Dscho