Le lundi 12 janvier 2009, Pierre Habouzit a écrit : > On Sun, Jan 11, 2009 at 07:47:18PM +0000, Alexey Zaytsev wrote: > > On Sun, Jan 11, 2009 at 22:42, Sam Ravnborg <sam@xxxxxxxxxxxx> 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. Well "git bisect" can be more usefull if it can be fully automated (with git bisect run) because then you can make the computer do all the boring work. So I think putting people on the "brainless course of actions" can often be a good thing. Anyway it looks to me that this kind of problem could be avoided if one could "replace" some commits only when bisecting. In this case what could be done is that one could "replace" the commit where btrfs is merged with one commit that cuts off the btrfs history. If the merge commit is only replaced when bisecting, then you get the best of both worlds: _ when you bisect, you don't see the btrfs history that breaks the kernel build, _ when you don't bisect, you see the full real history. Of course if the bisection process finds out that the "replaced" commit is the culprit, then you need to understand what this means... Regards, Christian. -- 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
