Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

["Philip Oakley" <philipoakley@iee.org>]

From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
> 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.