From: Philip Oakley Date: Wed, 15 Feb 2017 23:57:41 GMT Subject: Re: [git-for-windows] Re: Continuous Testing of Git on Windows Message-ID: <77C7E23E18774409AA1818B12C844985@PhilipOakley> In-Reply-To: From: "Johannes Schindelin" > Hi Philip, > > On Tue, 14 Feb 2017, Philip Oakley wrote: > >> From: "Christian Couder" >> > On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano >> > wrote: >> > > Johannes Schindelin writes: >> > > >> > > > On Mon, 13 Feb 2017, Junio C Hamano wrote: >> > > > >> > > > > Johannes Schindelin 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 was expecting that if all the second parents were marked as good, then there would be no merge bases, as there shouldn't be a forked graph, just the linear string of pearls - if bisect doesn't do that then there's an failed optimisation to be had. I don't see anything in the `git bisect --help` page that would indicate that the merges themselves are omitted from the bisection. > > 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. It may even be worth 'splitting' the pu branch sequence into the existing pu (with merges from series that are selected as reasonable), and then a pr branch (public review?) on top of that holding the rest of the series that have been submitted, so that the CI can do a full test on the tips of them to support those devs with limited test capability. > > Ciao, > Dscho >