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

Re: git pull on Linux/ACPI release tree

From
JSJohannes Schindelin <johannes.schindelin-mmb7mzphnfy@public.gmane.org>
Date
Jan 10, 2006, 18:45 UTC
Message-ID
<Pine.LNX.4.63.0601101938420.26999@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To
<Pine.LNX.4.64.0601101015260.4939-hNm40g4Ew95AfugRpC6u6w@public.gmane.org>
Hi,
On Tue, 10 Jan 2006, Linus Torvalds wrote:
Show 21 quoted lines
> 
> On Tue, 10 Jan 2006, Kyle Moffett wrote:
> >
> > On Jan 10, 2006, at 01:38, Martin Langhoff wrote:
> > > 
> > > The more complex your tree structure is, the more the interactions are
> > > likely to be part of the problem. Is git-bisect not useful in this scenario?
> > 
> > IIRC git-bisect just does an outright linearization of the whole tree anyways,
> > which makes git-bisect work everywhere, even in the presence of difficult
> > cross-merges.
> 
> It's not really a linearization - at no time does git-bisect _order_ the 
> commits. After all, no linear order actually exists. 
> 
> Instead, it really cuts the tree up into successively smaller parts. 
> 
> Think of it as doing a binary search in a 2-dimensional surface - you 
> can't linearize the plane, but you can decide to test first one half of 
> the surface, and then depending on whether it was there, you can halve 
> that surface etc.. 
How?

If you bisect, you test a commit. If the commit is bad, you assume *all* commits before that as bad. If it is good, you assume *all* commits after that as good.

Now, if you have a 2-dimensional surface, you don't have a *point*, but typically a *line* separating good from bad.

Further, the comparison with 2 dimensions is particularly bad. You *have* partially linear development lines, it got *nothing* to do with an area. The commits still make up a *list*, and it depends how you *order* that list for bisect. (And don't tell me they are not ordered: they are.)

If you order the commits by date, you don't get anything meaningful point before which it is bad, and after which it is good.

So, how is bisect supposed to work if you don't have one straight development line from bad to good?

Ciao, Dscho

- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Previous: Linus TorvaldsNext: Linus Torvalds
Message 11 of 19 in “RE: git pull on Linux/ACPI release tree”
  1. Linus TorvaldsJan 9, 2006
  2. Luben TuikovJan 9, 2006
  3. Linus TorvaldsJan 9, 2006
  4. Martin LanghoffJan 9, 2006
  5. Linus TorvaldsJan 10, 2006
  6. Junio C HamanoJan 10, 2006
  7. Kyle MoffettJan 10, 2006
  8. Martin LanghoffJan 10, 2006
  9. Kyle MoffettJan 10, 2006
  10. Linus TorvaldsJan 10, 2006
  11. Johannes SchindelinJan 10, 2006
  12. Linus TorvaldsJan 10, 2006
  13. Linus TorvaldsJan 10, 2006
  14. Johannes SchindelinJan 10, 2006
  15. Linus TorvaldsJan 10, 2006
  16. Linus TorvaldsJan 10, 2006
  17. Johannes SchindelinJan 10, 2006
  18. Matthias UrlichsJan 13, 2006
  19. Luben TuikovJan 11, 2006

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.