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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 15, 2017, 14:22 UTC
Message-ID: <alpine.DEB.2.20.1702151509251.3496@virtualbox>
In-Reply-To: <E2C1B7A8FBF94C8CB1C9C5754D882800@PhilipOakley>

Hi Philip,

On Tue, 14 Feb 2017, Philip Oakley wrote:

Show 29 quoted lines

> From: "Christian Couder" <christian.couder@gmail.com>
> > On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano <gitster@pobox.com>
> > wrote:
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > > > 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.
> >
> > 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