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

Re: Feature request: don't require both bad and good when bisecting

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 19, 2012, 16:49 UTC
Message-ID
<7vobrsbkoe.fsf@alter.siamese.dyndns.org>
In-Reply-To
<4F675DD3.3040004@op5.se>
Andreas Ericsson <ae@op5.se> writes:
Show 5 quoted lines
> It's sort of beside the point though. Using git as experiment (again),
> we're looking at less than 30000 revisions and 289 non-rc tags. With only
> 30k revisions, you'll do *worse* testing 15 tags sequentially than you
> would by just letting the bisection machinery get on with it and use
> the full history as base for bisection.
I think you are missing the primary point in what Jeff said.

It does not matter if you inspect increasingly older versions based on exponentially longer strides or if you test tagged releases. What matters is to making intelligent determination after seeing a failure, between the failure due to "the feature being tested did not even exist" and "the feature when introduced was good but at this commit it is broken".

Previous: Jeff King
Message 6 of 6 in “Feature request: don't require both bad and good when bisecting”
  1. darxus@chaosreigns.comMar 18, 2012
  2. Andreas EricssonMar 19, 2012
  3. Jeff KingMar 19, 2012
  4. Andreas EricssonMar 19, 2012
  5. Jeff KingMar 19, 2012
  6. Junio C HamanoMar 19, 2012

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.