git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Alex Hoffman <spec@gal.ro>
Cc: Stephan Beyer <s-beyer@gmx.net>, git@vger.kernel.org
Subject: Re: Git bisect does not find commit introducing the bug
Date: Sat, 18 Feb 2017 15:18:45 +0100	[thread overview]
Message-ID: <477d3533-d453-9499-e06e-72f45488d421@kdbg.org> (raw)
In-Reply-To: <CAMX8fZVkBU6M8fkUcRr69V97_NTSOGGmPB1U-ObhmVv3i6wQhg@mail.gmail.com>

Am 18.02.2017 um 12:15 schrieb Alex Hoffman:
> No one commented the fact, that I find this very confusing. Don't you
> find this confusing? I will underline, that 'git bisect good v.good'
> will fail if the commit 'v.good' is not a parent of the bad commit,
> meaning there MUST be at least a path between 'v.good' and 'v.bad',
> thus I would expect it looks on this path ONLY. Beside that, this is
> what I understand by 'binary search' (to search on this commit path).

But this is not how Git works. Git computes graph differences, i.e., it 
subtracts from the commits reachable from v.bad those that are reachable 
from v.good. This leaves more than just those on some path from v.good 
to v.bad. And it should work this way. Consider this history:

--o--o--o--G--X
    \           \
     x--x--x--x--X--B--

When you find B bad and G good, than any one of the x or X may have 
introduced the breakage, not just one of the X.

>> Correct. The assumption of bisection is that there is only one
>> transition between GOOD and BAD. By violating that assumption,
>> anything  can happen.
>
> I did not find that in the manpage or did I miss it? Why would someone
> assume that the commit graph looks in a certain way?

There is no restriction in the commit graph. The only restriction, 
actually assumption, is that there is *one* transition from good to bad 
and no transition from bad to good. Otherwise, bisection cannot work.

> I assume, that
> 'git bisect' was not thought through and that it considers the first
> directed path between v.good and v.bad, instead of all paths (in my
> example graph there are two such paths). I will also underline that
> git bisect was designed to work with multiple good commits and one bad
> commit (also multiple paths), but probably NOT with multiple paths
> between the same pair of good and bad commits.

Oh, IMO git bisect was well thought through. If it considered just paths 
from good to bad, it would not given the correct answer. See the example 
history above. Bisect authors would not have deemed that sufficiently 
good ;)

-- Hannes


  reply	other threads:[~2017-02-18 14:18 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-17 22:29 Git bisect does not find commit introducing the bug Alex Hoffman
2017-02-17 23:21 ` Stephan Beyer
2017-02-18  9:12   ` Johannes Sixt
2017-02-18 11:15     ` Alex Hoffman
2017-02-18 14:18       ` Johannes Sixt [this message]
2017-02-18 18:36         ` Alex Hoffman
2017-02-18 19:58           ` Christian Couder
2017-02-19 11:32             ` Alex Hoffman
2017-02-19 12:43               ` Alex Hoffman
2017-02-19 13:07               ` Christian Couder
2017-02-19 14:13               ` Johannes Sixt
2017-02-19 19:05                 ` Alex Hoffman
2017-02-19 19:25                   ` Jacob Keller
2017-02-20  7:38                     ` Oleg Taranenko
2017-02-20 12:27                       ` Jakub Narębski
2017-02-20 13:50                         ` Oleg Taranenko
2017-02-20 20:31                           ` Alex Hoffman
2017-02-20 20:35                             ` Jakub Narębski
2017-02-20 20:39                               ` Alex Hoffman
2017-02-20 22:24                               ` Philip Oakley
2017-02-21 19:40                                 ` Alex Hoffman
2017-02-21 22:39                                   ` Philip Oakley
2017-02-20  9:02             ` Junio C Hamano
2017-02-18 22:10           ` Philip Oakley
2017-02-18 22:36           ` Hilco Wijbenga
2017-02-18 22:37           ` Johannes Sixt

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=477d3533-d453-9499-e06e-72f45488d421@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=git@vger.kernel.org \
    --cc=s-beyer@gmx.net \
    --cc=spec@gal.ro \
    /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).