From: "Johannes Schindelin" <Johannes.Schindelin@xxxxxx>
Hi Philip,
On Tue, 14 Feb 2017, Philip Oakley wrote:
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
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