git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev

From
Christian Couder <chriscool@tuxfamily.org>
Date
Jul 10, 2008, 19:26 UTC
Message-ID
<200807102126.37567.chriscool@tuxfamily.org>
In-Reply-To
<alpine.DEB.1.00.0807101201210.3135@eeepc-johanness>
Hi,
Le jeudi 10 juillet 2008, Johannes Schindelin a écrit :
Show 11 quoted lines
> Hi,
>
> On Thu, 10 Jul 2008, Christian Couder wrote:
> > Before this patch, "git bisect", when it was given some good revs that
> > are not ancestor of the bad rev, didn't check if the merge bases were
> > good. "git bisect" just supposed that the user knew what he was doing,
> > and that, when he said the revs were good, he knew that it meant that
> > all the revs in the history leading to the good revs were also
> > considered good.
>
> Well, it is not completely relying on the user.
Yeah it's relying on statistics too.
> The common scenario before a bisect is this: something used to work _all
> the time_, and all of a sudden, it does not anymore.

I agree that it is the most common scenario, perhaps 95% or perhaps even 99% or more. But mistakes and special cases happens too.

For example people can forget to apply in the trunk a fix that is in a side branch. Or they can revert in a side branch a big buggy feature just before making a minor release; but in the trunk the big buggy feature is still there and may very well have introduced regressions.

Show 6 quoted lines
> So it is expected that there is no fix in the history.  Not in the
> current branch, not in the "good" branch, not wherever.
>
> In that case, you are literally guaranteed that all ancestors of a good
> commit are good, too, because if there was a bad one, there would be a
> fix, too.
Yeah, in that case...
> The whole idea of "bisect" relies on that idea, that any ancestor of a
> good commit is good.  Otherwise you'd have to check the commits one by
> one, not in a bisecting manner.

No, you just need to check that the merge bases between the bad rev on one side and each good rev on the other side are good too. And if that is the case, then you can be sure that bisection will point to a first bad commit.

So the choice is between a simple and fast but not fully reliable bisect, or a more complex and slower but fully reliable bisect.

Regards, Christian.

Previous: Johannes SchindelinNext: Junio C Hamano
Message 3 of 18 in “bisect: test merge base if good rev is not an ancestor of bad rev”
  1. bisect: test merge base if good rev is not an ancestor of bad revChristian Couder, Jul 10, 2008
  2. Johannes SchindelinJul 10, 2008
  3. Christian CouderJul 10, 2008
  4. Junio C HamanoJul 10, 2008
  5. Junio C HamanoJul 10, 2008
  6. Christian CouderJul 10, 2008
  7. Johannes SchindelinJul 10, 2008
  8. Christian CouderJul 10, 2008
  9. Junio C HamanoJul 10, 2008
  10. Christian CouderJul 10, 2008
  11. Junio C HamanoJul 10, 2008
  12. Johannes SchindelinJul 10, 2008
  13. Junio C HamanoJul 11, 2008
  14. Johannes SchindelinJul 11, 2008
  15. Junio C HamanoJul 10, 2008
  16. Christian CouderJul 13, 2008
  17. Johannes SchindelinJul 13, 2008
  18. Christian CouderJul 22, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.