On Mon, Jan 12, 2009 at 01:17:31AM +0300, Alexey Zaytsev wrote: > 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? Yep - you miss that people get confused when suddenly they have no kernel source. Sam -- 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
