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

Re: Git bisect does not find commit introducing the bug

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 20, 2017, 09:02 UTC
Message-ID
<xmqqy3x1jkuu.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<CAP8UFD3ngMvVy2XLzYNn9OFbS+zQpWTW=pravpHhA-0PcDVhfg@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> git bisect makes some assumptions that are true most of the time, so
> in practice it works well most of the time.

I think we need to clarify the documentation and ask you to stop using such fuzzy phrases like "assumptions" and "most of the time" ;-).

For bisection to work, "git bisect" requires a very simple thing, which is that your history is bisectable wrt one particular "trait", i.e. what you are interested in (e.g. the trait may be "the commit has this feature in a broken form").

What does it mean for a history to be "bisectable", then?

A bisectable history has commits with the "trait" and commits without the "trait". Given any commit with the "trait", all commits that are decendant of such commit must have the "trait". Also given any commit without the "trait", all commits that are ancestor of such a commit must not have the "trait".

And your goal is to find one commit with the "trait" whose direct parent commits all lack the "trait".

If and only if you can formulate your problem into the above form, "git bisect" can help you by not requiring you to check each and every commit in the history.

Depending on the way you define the "trait", your history may not be bisectable, but by formulating the "trait" carefully, many such history can be made bisectable. In the "Recently some commit broke feature X. Before then the feature used to work. In an ancient past, the feature did not even exist" example, if you set "trying to use feature X breaks" as the "trait", your history is not bisectable unless you ignore the ancient part that did not even have the feature. If you restate your "trait" to "feature X does not exist in a broken form", however, the history becomes bisectable.

Historically, we called commits with "trait" BAD and others GOOD, because bisection was used primarily to hunt for bugs. It may be easier to understand if the user thinks of commits without "trait" as OLD (i.e. commits in the older part of the history are not yet contaminated), and commits with "trait" as NEW (i.e. at some point, there is an event to introduce the "trait" and newer part of the history is contaminated by that event ever since).

Previous: Philip OakleyNext: Philip Oakley
Message 23 of 26 in “Git bisect does not find commit introducing the bug”
  1. Alex HoffmanFeb 17, 2017
  2. Stephan BeyerFeb 17, 2017
  3. Johannes SixtFeb 18, 2017
  4. Alex HoffmanFeb 18, 2017
  5. Johannes SixtFeb 18, 2017
  6. Alex HoffmanFeb 18, 2017
  7. Christian CouderFeb 18, 2017
  8. Alex HoffmanFeb 19, 2017
  9. Alex HoffmanFeb 19, 2017
  10. Christian CouderFeb 19, 2017
  11. Johannes SixtFeb 19, 2017
  12. Alex HoffmanFeb 19, 2017
  13. Jacob KellerFeb 19, 2017
  14. Oleg TaranenkoFeb 20, 2017
  15. Jakub NarębskiFeb 20, 2017
  16. Oleg TaranenkoFeb 20, 2017
  17. Alex HoffmanFeb 20, 2017
  18. Jakub NarębskiFeb 20, 2017
  19. Alex HoffmanFeb 20, 2017
  20. Philip OakleyFeb 20, 2017
  21. Alex HoffmanFeb 21, 2017
  22. Philip OakleyFeb 21, 2017
  23. Junio C HamanoFeb 20, 2017
  24. Philip OakleyFeb 18, 2017
  25. Hilco WijbengaFeb 18, 2017
  26. Johannes SixtFeb 18, 2017

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.