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

Re: current git kernel has strange problems during bisect

From
Pierre Habouzit <madcoder@debian.org>
Date
Jan 11, 2009, 23:02 UTC
Message-ID
<20090111230240.GA27489@artemis.corp>
In-Reply-To
<f19298770901111147t625a2161t779bfcfc0317225c@mail.gmail.com>
On Sun, Jan 11, 2009 at 07:47:18PM +0000, Alexey Zaytsev wrote:
Show 23 quoted lines
> On Sun, Jan 11, 2009 at 22:42, Sam Ravnborg <sam@ravnborg.org> wrote:
> >>
> >> For bisect, it's indeed somewhat annoying, and we could have perhaps done
> >> some things a bit differently, but it's about the closest you can get to
> >> "real history" without making the first btrfs merge-point a _total_
> >> disaster.
> >>
> >> For bisect purposes, if you know you're not chasing down a btrfs issue,
> >> you can do
> >>
> >>       git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8
> >>
> >> where that commit 34353029 is the last one which has _just_ the btrfs
> >> files. The next commit is when it does "Merge Btrfs into fs/btrfs", and
> >> that one has the whole kernel tree again.
> >
> > The cost of moving this piece of history from one git tree to another
> > git tree is that we make it harder to debug the kernel for the advanced user
> > that knows how to do bisect.
> 
> And wasn't is trivial to avoid? Just exporting the commits as
> patches and importing them into the kernel tree would preserve
> the history, and not break bisection.

And would have brought a whole history of totally irrelevant stuff that never exited for real, with probably a lot of non-compiling sub-steps which would be even worse.

No, the two possible choices were to squash the whole stuff at once, or do what has been done IMNSHO. People have to grok how to take shortcuts with git-bisect. I know that git-bisect puts people on the brainless course of actions where they git-bisect; configure; compile; boot; test; mark as good/bad and retry. And that's what I sometimes don't like with it. Because people trust git-bisect too much and forget how to think right.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
Previous: Alexey ZaytsevNext: Christian Couder
Message 9 of 23 in “current git kernel has strange problems during bisect”
  1. Christian BorntraegerJan 11, 2009
  2. Christian BorntraegerJan 11, 2009
  3. Johannes SchindelinJan 11, 2009
  4. Christian BorntraegerJan 11, 2009
  5. Boaz HarroshJan 11, 2009
  6. Linus TorvaldsJan 11, 2009
  7. Sam RavnborgJan 11, 2009
  8. Alexey ZaytsevJan 11, 2009
  9. Pierre HabouzitJan 11, 2009
  10. Christian CouderJan 12, 2009
  11. Christian CouderJan 12, 2009
  12. Linus TorvaldsJan 11, 2009
  13. Christian BorntraegerJan 11, 2009
  14. Daniel BarkalowJan 11, 2009
  15. Kyle MoffettJan 13, 2009
  16. Andreas BombeJan 15, 2009
  17. Kyle MoffettJan 15, 2009
  18. Sam RavnborgJan 11, 2009
  19. Alexey ZaytsevJan 11, 2009
  20. Sam RavnborgJan 11, 2009
  21. Daniel BarkalowJan 11, 2009
  22. Andi KleenJan 11, 2009
  23. Johannes SchindelinJan 11, 2009

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.