From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Christian Couder <christian.couder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Lars Schneider <larsxschneider@gmail.com>,
git <git@vger.kernel.org>, Jeff King <peff@peff.net>,
Brandon Williams <bmwill@google.com>
Subject: Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)
Date: Sat, 22 Apr 2017 13:48:41 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1704221319580.3480@virtualbox> (raw)
In-Reply-To: <CAP8UFD19DVqQLHBta74uLcFPwJaRUKF8Ppmnhct5ub=OkKSqCQ@mail.gmail.com>
Hi Christian,
On Fri, 21 Apr 2017, Christian Couder wrote:
> On Fri, Apr 21, 2017 at 11:50 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > (with all associated problems I reported earlier, as you apply some
> > patches on top of really ancient commits and bisect wants to test all
> > merge bases first)
>
> First bisect should ask you to test merge bases only if there are
> "good" commits that are not ancestors of the "bad" commit.
Please note that this is a stateless job. The only "state" I have is the
branch name.
So when something goes wrong, I have *no* indicator what is a known good
state.
The strategy I implemented was to use knowledge about the branches and
their relations. So when there is a bug in `pu`, the script first tests
whether the same test passes in `next`. And if it does, that is my
known-good state.
In the meantime, I cheat and mark all merge-bases as known-good, too. But
that is by no means a correct assumption: sometimes Junio decides to base
a patch on top of a really ancient commit, one that may be broken on
Windows. So there you are, I cannot win, I just tried to implement
something that works reasonably well, most of the time. It still takes way
too long.
> Second yeah there is probably an old bug in bisect there. In theory in
> most cases bisect should ask you to test only one merge base, as:
>
> - if the merge base is "bad", it means that the bug has been fixed
> between the merge base and your "good" commit, and bisecting will
> stop,
> - if the merge base is "good", it means that all the merge bases that
> are ancestor of this merge base are also good, so there is no need to
> test them
That is not necessarily correct. If there are two merge bases, one may be
broken, and then that one is the first bad commit.
> > because the required time *definitely* would let Travis time out all
> > the time. Those bisect results are even less visible than the Travis
> > results, see e.g.
> > https://github.com/git/git/commit/2e3a8b9035a#commitcomment-21836854.
>
> Nice that they exists though!
Yeah, well, it took enough of my time to implement, too ;-)
Ciao,
Dscho
next prev parent reply other threads:[~2017-04-22 11:49 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 5:37 What's cooking in git.git (Apr 2017, #04; Wed, 19) Junio C Hamano
2017-04-20 9:59 ` Duy Nguyen
2017-04-20 15:35 ` Jeff King
2017-04-20 22:51 ` Junio C Hamano
2017-04-20 22:46 ` Junio C Hamano
2017-04-20 15:32 ` Lars Schneider
2017-04-20 22:52 ` Junio C Hamano
[not found] ` <D61D47BD-9750-4FB6-892E-013504E03738@gmail.com>
2017-04-20 13:24 ` Johannes Schindelin
2017-04-20 16:56 ` Brandon Williams
2017-04-20 23:18 ` Brandon Williams
2017-04-21 0:56 ` Junio C Hamano
2017-04-20 22:58 ` Junio C Hamano
2017-04-21 9:50 ` Johannes Schindelin
2017-04-21 12:29 ` Christian Couder
2017-04-22 11:48 ` Johannes Schindelin [this message]
2017-04-22 17:32 ` Christian Couder
2017-04-24 14:08 ` Johannes Schindelin
2017-04-22 13:37 ` Johannes Sixt
2017-04-24 14:24 ` Johannes Schindelin
2017-04-24 16:34 ` Philip Oakley
2017-04-25 2:17 ` Christian Couder
2017-04-25 2:00 ` Christian Couder
2017-04-25 5:51 ` Johannes Sixt
2017-04-25 6:52 ` Junio C Hamano
2017-04-25 18:26 ` Johannes Sixt
2017-04-24 0:25 ` Junio C Hamano
2017-04-24 14:19 ` Johannes Schindelin
2017-04-24 15:18 ` Ævar Arnfjörð Bjarmason
2017-04-25 0:56 ` Junio C Hamano
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=alpine.DEB.2.20.1704221319580.3480@virtualbox \
--to=johannes.schindelin@gmx.de \
--cc=bmwill@google.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=larsxschneider@gmail.com \
--cc=peff@peff.net \
/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).