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

Re: [RFC/PATCH]: reverse bisect v 2.0

From
Andrew Ardill <andrew.ardill@gmail.com>
Date
Oct 7, 2011, 01:57 UTC
Message-ID
<CAH5451kUf=vPfgOOusmJjfbiyueX9VByJLzZ9WbyqLd0z78wxA@mail.gmail.com>
In-Reply-To
<7v62k4ban7.fsf@alter.siamese.dyndns.org>

Hi, I have given this some thought and have a slightly different proposal for the options to use. I have written a commit message that I think explains the need for the improvement, and justifies my proposal. The options I propose are '--intoduced' and '--removed'.

--->8---

Bisect is used to look for a commit that causes a specific change. Such a change can be classified by the user as either introducing something, or removing something, and this distinction is arbitrary. A change could be said to introduce a bug fix, or remove a bug - both formulations have inherently the same meaning, but search behaviour changes depending on which one we use. Suppose I want to find the commit that removed a bug. If I examine a snapshot and it contains the bug, the bug has not yet been *removed* and I must look in the future for its removal. Conversely, if I examine a snapshot and the bug fix exists, the bug fix must have been *introduced* at some earlier point and so I must search backwards.

Confusion exists at this point because at each verification step a question like 'Does this snapshot have X?' is asked, when what we eventually want to know is 'When was X introduced?' or 'When was X removed?'. Previously there has been no way to specify if we are looking for X being introduced or removed; it was assumed that we were looking for when something was introduced, for example when a bug was introduced.

Teach git bisect if we are looking for when something was introduced or when something was removed.

Examples.
Search for a feature add:
   $ git bisect start --introduced='feature: git frotz says xyzzy' v0.99 master
   Bisecting: 171 revisions left to test after this (roughly 8 steps)
   $ ... build and then test ...
   $ git bisect tested
   Does this snapshot have 'feature: git frotz says xyzzy' [y/n]? yes
# already added, look backwards
Search for a feature regression:
   $ git bisect start --removed='feature: git frotz says xyzzy' v0.99 master
   Bisecting: 171 revisions left to test after this (roughly 8 steps)
   $ ... build and then test ...
   $ git bisect tested
   Does this snapshot have 'feature: git frotz says xyzzy' [y/n]? yes
# not removed yet, look forwards
--->8---
Regards,
Andrew Ardill
Previous: Junio C HamanoNext: Junio C Hamano
Message 15 of 17 in “RFC: reverse bisect”
  1. Michal VyskocilSep 29, 2011
  2. Sverre RabbelierSep 29, 2011
  3. Johannes SixtSep 29, 2011
  4. Jeff KingSep 30, 2011
  5. Frans KlaverSep 30, 2011
  6. Michal VyskocilSep 30, 2011
  7. : reverse bisect v 2.0Michal Vyskocil, Sep 30, 2011
  8. Junio C HamanoSep 30, 2011
  9. Jeff KingOct 3, 2011
  10. Junio C HamanoOct 3, 2011
  11. Jeff KingOct 4, 2011
  12. Junio C HamanoOct 4, 2011
  13. Christian CouderOct 4, 2011
  14. Junio C HamanoOct 4, 2011
  15. Andrew ArdillOct 7, 2011
  16. Junio C HamanoOct 12, 2011
  17. Jeff KingOct 12, 2011

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.