From: Junio C Hamano <hidden> Date: 2017-02-14 21:08:22
Johannes Schindelin [off-list ref] writes:
On Mon, 13 Feb 2017, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
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.
Probably a less resource intensive approach is to find the tips of
the topics not in 'next' but in 'pu' and test them. That would give
you which topic(s) are problematic, which is a better starting point
than "Oh, 'pu' does not build". After identifying which branch is
problematic, bisection of individual topic would be of more manageable
size.
$ git log --first-parent --oneline 'pu^{/^### match next}..pu'
will you the merges of topics left outside 'next'. I often reorder
to make the ones that look more OK than others closer to the bottom,
and if the breakages caused by them are caught earlier than they hit
'next', that would be ideal.
This is one of these times I wish "git bisect --first-parent" were
available. The above "log" gives me 27 merges right now, which
should be bisectable within 5 rounds to identify a single broken
topic (if there is only one breakage, that is).
From: Christian Couder <hidden> Date: 2017-02-14 23:01:05
On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano [off-list ref] wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Mon, 13 Feb 2017, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
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.
Probably a less resource intensive approach is to find the tips of
the topics not in 'next' but in 'pu' and test them. That would give
you which topic(s) are problematic, which is a better starting point
than "Oh, 'pu' does not build". After identifying which branch is
problematic, bisection of individual topic would be of more manageable
size.
It is still probably more resource intensive than it couls be.
[...]
This is one of these times I wish "git bisect --first-parent" were
available.
Implementing "git bisect --first-parent" is also part of the GSoC 2017 Ideas.
By the way it should not be very difficult as a patch to do this and
more was proposed a long time ago:
https://public-inbox.org/git/4D3CDDF9.6080405@intel.com/
The above "log" gives me 27 merges right now, which
should be bisectable within 5 rounds to identify a single broken
topic (if there is only one breakage, that is).
From: Philip Oakley <hidden> Date: 2017-02-14 23:27:07
From: "Christian Couder" <redacted>
On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano [off-list ref]
wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
On Mon, 13 Feb 2017, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
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.
Probably a less resource intensive approach is to find the tips of
the topics not in 'next' but in 'pu' and test them. That would give
you which topic(s) are problematic, which is a better starting point
than "Oh, 'pu' does not build". After identifying which branch is
problematic, bisection of individual topic would be of more manageable
size.
It is still probably more resource intensive than it couls be.
[...]
quoted
This is one of these times I wish "git bisect --first-parent" were
available.
Implementing "git bisect --first-parent" is also part of the GSoC 2017
Ideas.
By the way it should not be very difficult as a patch to do this and
more was proposed a long time ago:
https://public-inbox.org/git/4D3CDDF9.6080405@intel.com/
quoted
The above "log" gives me 27 merges right now, which
should be bisectable within 5 rounds to identify a single broken
topic (if there is only one breakage, that is).
From: Johannes Schindelin <hidden> Date: 2017-02-15 14:07:58
Hi Christian,
On Wed, 15 Feb 2017, Christian Couder wrote:
On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano [off-list ref]
wrote:
quoted
Probably a less resource intensive approach is to find the tips of the
topics not in 'next' but in 'pu' and test them. That would give you
which topic(s) are problematic, which is a better starting point than
"Oh, 'pu' does not build". After identifying which branch is
problematic, bisection of individual topic would be of more manageable
size.
It is still probably more resource intensive than it couls be.
From: Johannes Schindelin <hidden> Date: 2017-02-15 14:23:07
Hi Philip,
On Tue, 14 Feb 2017, Philip Oakley wrote:
From: "Christian Couder" <redacted>
quoted
On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano [off-list ref]
wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
On Mon, 13 Feb 2017, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
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.
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 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.
Ciao,
Dscho
From: Philip Oakley <hidden> Date: 2017-02-15 23:57:41
From: "Johannes Schindelin" <redacted>
Hi Philip,
On Tue, 14 Feb 2017, Philip Oakley wrote:
quoted
From: "Christian Couder" <redacted>
quoted
On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano [off-list ref]
wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
On Mon, 13 Feb 2017, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
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.
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.