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