Hi Junio, On Thu, 7 Feb 2019, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > Even when there are even only as much as 12 merge bases to test (which is > > the current number of merge bases between `next` and `pu`),... > > ... > > And I sadly have to report that that's not the end of it. Back when I > > implemented the automatic bisect after failed builds (for details, see > > https://github.com/git-for-windows/build-extra/commit/c7e01e82c), I had to > > turn it off real quickly because the dumb bisect between `next` and `pu` > > regularly ran into the 4h timeout. > > Would it make it easier for you if you substituted all the mention > of 'next' in your message with 'pu^{/^### match next}'? I was working on this in 2017, and could not make it to work as I wanted. Ever since, that bisect code has been dormant. In the meantime, I was able to parallelize the test suite enough to make it feasible to test the topic branches. That usually takes care of things really quickly, and I just bite the bullet and bisect manually. Ciao, Dscho > > That mid-point between 'master' and 'pu' is designed to contain > exactly the same set of non-merge commits 'next' has, with the tree > that is identical to that of 'next', and from there to the tip of > 'pu' forms a single strand of merges of tips of topic branches that > are not yet merged to 'next' (by definition, it itself is the merge > base of it and 'pu'). > > Bisecting along the first-parent chain from there to the tip of 'pu' > would let us identify which merge is faulty as the first-and-quick > pass and currently there are about 20 merges in that range on the > first-parent chain. > >
