Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)
- From
Philip Oakley <philipoakley@iee.org>
- Date
- Apr 24, 2017, 16:34 UTC
- Message-ID
- <ADC645666B1F4ECA92E9082F0565F475@PhilipOakley>
- In-Reply-To
- <alpine.DEB.2.20.1704241622510.3480@virtualbox>
From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Show 29 quoted lines
> Hi Hannes, > > On Sat, 22 Apr 2017, Johannes Sixt wrote: > >> Am 21.04.2017 um 14:29 schrieb Christian Couder: >> > First bisect should ask you to test merge bases only if there are >> > "good" commits that are not ancestors of the "bad" commit. >> >> That's a tangent, but I have never understood why this needs to be so. >> Consider this: >> >> o--o--o--o--o--o--o--o--B >> / / >> -o--o--o--o--g--o--o--o--o--G >> >> When I mark B as bad and G as good, why would g have to be tested first? >> This >> is exactly what I do when I bisect in Git history: I mark the latest >> commits >> on git-gui and gitk sub-histories as good, because I know they can't >> possibly >> be bad. (In my setup, these two histories are ahead of pu and next.) > > I guess the idea behind bisect's reasoning is that you could have merged > the "wrong" branch first. > > Ciao, > Dscho >
Sorry if I'm bikeshedding here, but it does look like adding an alternate 'bisect' strategy may be useful for this style of integration testing.
To me, given the multiplicity of independent branches being brought together, it should be possible to do a check on each of the branches separately, before the tests along the line of integration . The tests would not be a true 'bisection' as they are separate single point tests, but they do establish good commits at the tips of those branches.
Thus, for each of the merges in the --first-parent traversal, the option could test (in the OS of choice) the *second parent* commit of the merge. This sets the known good points. The breakages during the integration then become easier to bisect, as it is only looking for the integration of a good series into mainline that breaks. [1]
In addition, an aside that dscho made earlier about the merge-base of some branches relative to Windows may have been missed. The normal bisect process assumes that we start from a set of good merge bases. However, dscho noticed that occasionally some series may choose an older point on maint (etc.) that itself would _not_ be classed as good when tested on Windows (or on other OS's). Those older mergebases can make the classic bisect across all the commits in the DAG between here and there a tortuous process, especially if the local OS implementation percieves the base points as bad! (which breaks expectations).
-- Philip
[1] It maybe that this can be approached via an alternate DAG, which could be 'faked' up as if each of the topic branches had been squashed from being a long series down to a single commit (the final tree of the series), and then likewise (same tree) for the integration merges, such that all the singleton commits are not tested, only the pre and post merge commits on the first-parent traverse.