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
Junio C Hamano <gitster@pobox.com>
Date
Jul 10, 2008, 23:24 UTC
Message-ID
<7v7ibtnx09.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<alpine.DEB.1.00.0807110035180.3279@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 8 quoted lines
> You are opening a can of worms here, and I doubt that this is a good idea.
>
> git-bisect as-is has very precise, and _simple_ semantics, and users 
> should really know what they are doing (i.e. not marking something as 
> "good" which is on a branch containing a fix).
>
> Trying to be too clever here might just make the whole tool rather 
> useless.

Have you read the original thread yet? I do not think this is trying to be clever at all, but trying to be helpful.

As you explained, bisection *requires* that Good is ancestor of Bad.
     ---o---?---?---?---x
        Good            Bad

But in real life, things are more like "Today's master does not work, but I am sure it used to work at 1.5.6.2". I happen to always merge all of 'maint' to 'master' before pushing them out, so a good topology is guaranteed, but not everybody does this (it takes careful planning what to apply to 'maint' and where to fork topics from, and maintainers are not perfect):

              Good
          ?---o (maint)
         /
     ---?---?---?---?---x (master)
        MB              Bad

People _will_ face such a topology. If the users Know Better, they will test MB=$(merge-base master maint) first to see if it is broken, and then the world will have two possibilities:

    (1)       Good
          ?---o (maint)
         /
     ---o---?---?---?---x (master)
        Good            Bad
    (2)       Good
          ?---o (maint)
         /
     ---x---?---?---?---x (master)
        Bad             Bad

If (1), you go ahead with the usual bisection. If (2), you cannot even bisect. Instead, you flip good and bad to find the "fix" in the side branch (the answer has to be either the tip of maint or one previous in the picture) to forward port to, either by merging 'maint' to 'master' or cherry-picking.

The idea to check merge-base first is about automating this process (I admit I still haven't looked at Christian's patch text yet).

Previous: Christian CouderNext: Christian Couder
Message 9 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.