From: "Philip Oakley" <philipoakley@iee.org>
To: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Cc: "Christian Couder" <christian.couder@gmail.com>,
"Junio C Hamano" <gitster@pobox.com>,
<git-for-windows@googlegroups.com>, "git" <git@vger.kernel.org>
Subject: Re: [git-for-windows] Re: Continuous Testing of Git on Windows
Date: Wed, 15 Feb 2017 23:57:23 -0000 [thread overview]
Message-ID: <77C7E23E18774409AA1818B12C844985@PhilipOakley> (raw)
In-Reply-To: alpine.DEB.2.20.1702151509251.3496@virtualbox
From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
> Hi Philip,
>
> On Tue, 14 Feb 2017, Philip Oakley wrote:
>
>> From: "Christian Couder" <christian.couder@gmail.com>
>> > On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano <gitster@pobox.com>
>> > wrote:
>> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > >
>> > > > On Mon, 13 Feb 2017, Junio C Hamano wrote:
>> > > >
>> > > > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > > > >
>> > > > > > 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.
>>
>> There are also a few ideas at the SO answers:
>> http://stackoverflow.com/a/5652323/717355
>
> 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.
>
> Ciao,
> Dscho
>
next prev parent reply other threads:[~2017-02-15 23:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-10 12:24 Continuous Testing of Git on Windows Johannes Schindelin
2017-02-13 23:46 ` Junio C Hamano
2017-02-14 20:55 ` [git-for-windows] " Johannes Schindelin
2017-02-14 21:08 ` Junio C Hamano
2017-02-14 23:00 ` Christian Couder
2017-02-14 23:11 ` Junio C Hamano
2017-02-14 23:27 ` Philip Oakley
2017-02-14 23:35 ` Junio C Hamano
2017-02-15 17:31 ` Philip Oakley
2017-02-15 21:26 ` Junio C Hamano
2017-02-15 23:33 ` Philip Oakley
2017-02-16 1:33 ` Junio C Hamano
2017-02-15 22:19 ` Philip Oakley
2017-02-15 22:19 ` Philip Oakley
2017-02-15 14:22 ` Johannes Schindelin
2017-02-15 23:57 ` Philip Oakley [this message]
2017-02-16 0:20 ` Junio C Hamano
2017-02-18 11:49 ` Philip Oakley
2017-02-15 14:07 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77C7E23E18774409AA1818B12C844985@PhilipOakley \
--to=philipoakley@iee.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=christian.couder@gmail.com \
--cc=git-for-windows@googlegroups.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).