On Sun, Jan 11, 2009 at 23:04, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On Sun, 11 Jan 2009, Sam Ravnborg wrote: >> >> 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. >> >> It is not like this history would be lost - one just had to look >> somewhere else to find it. >> >> That may be a bad pain/benefit ratio - time will tell. > > Umm. No. > > Time is exactly what makes it useful. It will make all the downsides > shrink, and the advantages stay. > >> There should be a way to avoid such pain when bisecting without >> having to mark a semi-random (for the average person) commit as good. > > Well, you don't actually have to mark that semi-random one as good either. > What you can do is to just mark anything that _only_ contains fs/btrfs as > good. IOW, you don't have to know the magic number - you just have to be > told that "oh, if you only have btrfs files, and you're not actively > bisecting a btrfs bug, just do 'git bisect good' and continue". > > Yeah, you'll hit it a few times, but you don't even have to compile things > or boot anything, so it's not actually going to be all that much slower > than just knowing about the magic point either. But would not such bug avoid being bisected if you blindly mark btrfs commits as good? v2.6.29 <-- bad ... ... ... btrfs stuff <-- mark as good ... the-real-bug ... v2.6.28 <-- good So you hit the btrfs commit, mark it as good, leaving the real bug below, and the bisection continues, with both sides being actually bad. Am I missing something? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
