From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: "SZEDER Gábor" <szeder.dev@gmail.com>,
"Philip Oakley" <philipoakley@iee.org>,
"Git Mailing list" <git@vger.kernel.org>
Subject: Re: "git bisect run make" adequate to locate first unbuildable commit?
Date: Mon, 12 Feb 2018 14:05:11 +0100 [thread overview]
Message-ID: <20180212130511.32620-1-szeder.dev@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.21.1802120512380.17034@localhost.localdomain>
> > 1. there may be feature branches that bypass the known good starting
> > commit, which can cause understanding issues as those side
> > branches that predate the start point are also considered
> > potential bu commits.
>
> ok, but let's make sure i understand what defines a possible commit
> that "introduces" the bug. if i define two bisection commits <good>
> and <bad>, then i've always assumed that what i'm after is a commit
> <X> for which:
>
> 1) <X> is reachable from <bad>
> 2) <good> is reachable from <X>
>
> this seems fairly obvious.
Well, maybe _you_ are after such a commit, but bisect is after a
commit <X> for which
1) <X> is reachable from <bad> (i.e. the same as your first point)
2) <X> is not reachable from <good> (which is not the same as your
second point, notably when it comes to commits on side branches
that branched off before <good> and got merged later).
> now, as you suggest, it's possible that the
> "bug" was introduced on a feature branch that bypasses my choice of
> <good> but, at *some* point, that feature branch would have to be
> merged to the point where it was now reachable from <bad> and, in the
> context of bisection, *that* merge commit would represent where the
> bug was introduced, no?
No. Consider this piece of history:
<good> <bad>
v v
--a---b---C---d---e---M---k---L--
\ /
f---g---H---i---j
^
first
bad
Then the command 'git bisect start L C' will first consider the
following as "possible commit that introduces the bug":
d e f g H i j M k L
(IOW all commits listed by 'git log ^C L') and will then
systematically narrow down until it will find commit H as the
transition from good to bad.
next prev parent reply other threads:[~2018-02-12 13:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-09 13:20 "git bisect run make" adequate to locate first unbuildable commit? Robert P. J. Day
2018-02-09 13:47 ` Christian Couder
2018-02-09 20:48 ` Philip Oakley, CEng MIET
2018-02-09 20:54 ` Robert P. J. Day
2018-02-09 22:44 ` Philip Oakley
2018-02-12 10:19 ` Robert P. J. Day
2018-02-12 13:05 ` SZEDER Gábor [this message]
2018-02-13 12:41 ` Robert P. J. Day
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=20180212130511.32620-1-szeder.dev@gmail.com \
--to=szeder.dev@gmail.com \
--cc=git@vger.kernel.org \
--cc=philipoakley@iee.org \
--cc=rpjday@crashcourse.ca \
/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).