{"thread":{"id":"17087","subject":"current git kernel has strange problems during bisect","startedAt":"2009-01-11T15:02:53Z","lastAt":"2009-01-15T23:13:30Z","messageCount":23,"participants":["Christian Borntraeger","Johannes Schindelin","Boaz Harrosh","Linus Torvalds","Sam Ravnborg","Alexey Zaytsev","Andi Kleen","Daniel Barkalow","Pierre Habouzit","Christian Couder","Kyle Moffett","Andreas Bombe"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"99965","messageId":"200901111602.53082.borntraeger@de.ibm.com","threadId":"17087","inReplyTo":null,"subject":"current git kernel has strange problems during bisect","fromName":"Christian Borntraeger","fromEmail":"borntraeger@de.ibm.com","sentAt":"2009-01-11T15:02:53Z","receivedAt":"2009-01-11T15:02:53Z","isPatch":false,"sender":{"key":"borntraeger@de.ibm.com","avatar":null},"body":"doing a \ngit bisect start\ngit bisect good a3a798c\ngit bisect bad v2.6.29-rc1\n\nresults in a repository without several files, e.g Makefile!\ngit describe also fails.\n\nAny ideas how to fix this problem to continue with my bisect?\n\nChristian\n"},{"id":"99966","messageId":"200901111607.59054.borntraeger@de.ibm.com","threadId":"17087","inReplyTo":"200901111602.53082.borntraeger@de.ibm.com","subject":"Re: current git kernel has strange problems during bisect","fromName":"Christian Borntraeger","fromEmail":"borntraeger@de.ibm.com","sentAt":"2009-01-11T15:07:59Z","receivedAt":"2009-01-11T15:07:59Z","isPatch":false,"sender":{"key":"borntraeger@de.ibm.com","avatar":null},"body":"Am Sonntag 11 Januar 2009 schrieb Christian Borntraeger:\n> doing a \n> git bisect start\n> git bisect good a3a798c\n> git bisect bad v2.6.29-rc1\n> \n> results in a repository without several files, e.g Makefile!\n> git describe also fails.\n\nIn fact, retesting with a clean repository shows, that there are only btrfs \nfiles - nothing else.\n\nLinus did you pull a broken btrfs repository?\n\nChristian\n"},{"id":"99968","messageId":"alpine.DEB.1.00.0901111613250.3586@pacific.mpi-cbg.de","threadId":"17087","inReplyTo":"200901111607.59054.borntraeger@de.ibm.com","subject":"Re: current git kernel has strange problems during bisect","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-11T15:14:03Z","receivedAt":"2009-01-11T15:14:03Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Jan 2009, Christian Borntraeger wrote:\n\n> Am Sonntag 11 Januar 2009 schrieb Christian Borntraeger:\n> > doing a \n> > git bisect start\n> > git bisect good a3a798c\n> > git bisect bad v2.6.29-rc1\n> > \n> > results in a repository without several files, e.g Makefile!\n> > git describe also fails.\n> \n> In fact, retesting with a clean repository shows, that there are only btrfs \n> files - nothing else.\n> \n> Linus did you pull a broken btrfs repository?\n\nI guess it is a subtree merge. So no, nothing went wrong\n\nUse \"git bisect skip\" to skip over those.\n\nHth,\nDscho\n"},{"id":"99969","messageId":"200901111620.03345.borntraeger@de.ibm.com","threadId":"17087","inReplyTo":"alpine.DEB.1.00.0901111613250.3586@pacific.mpi-cbg.de","subject":"Re: current git kernel has strange problems during bisect","fromName":"Christian Borntraeger","fromEmail":"borntraeger@de.ibm.com","sentAt":"2009-01-11T15:20:03Z","receivedAt":"2009-01-11T15:20:03Z","isPatch":false,"sender":{"key":"borntraeger@de.ibm.com","avatar":null},"body":"\nAm Sonntag 11 Januar 2009 schrieben Sie:\n> Hi,\n> \n> On Sun, 11 Jan 2009, Christian Borntraeger wrote:\n> \n> > Am Sonntag 11 Januar 2009 schrieb Christian Borntraeger:\n> > > doing a \n> > > git bisect start\n> > > git bisect good a3a798c\n> > > git bisect bad v2.6.29-rc1\n> > > \n> > > results in a repository without several files, e.g Makefile!\n> > > git describe also fails.\n> > \n> > In fact, retesting with a clean repository shows, that there are only \nbtrfs \n> > files - nothing else.\n> > \n> > Linus did you pull a broken btrfs repository?\n> \n> I guess it is a subtree merge. So no, nothing went wrong\n> \n> Use \"git bisect skip\" to skip over those.\n\nI think we should really avoid merging subtrees to the linux kernel. It makes \nbisecting a real PITA. \nFurthermore, It is unlikely, but what if the problem is part of the 581 \nchangesets from btrfs?\n\nChristian\n"},{"id":"99972","messageId":"496A1EF3.20204@panasas.com","threadId":"17087","inReplyTo":"200901111620.03345.borntraeger@de.ibm.com","subject":"Re: current git kernel has strange problems during bisect","fromName":"Boaz Harrosh","fromEmail":"bharrosh@panasas.com","sentAt":"2009-01-11T16:31:47Z","receivedAt":"2009-01-11T16:31:47Z","isPatch":false,"sender":{"key":"bharrosh@panasas.com","avatar":"https://gravatar.com/avatar/347e426f8ca0409f6891ceeefd4c3c2d8769608382323057efeaa362b4c3dbf3?d=mp&s=160"},"body":"Christian Borntraeger wrote:\n> Am Sonntag 11 Januar 2009 schrieben Sie:\n>> Hi,\n>>\n>> On Sun, 11 Jan 2009, Christian Borntraeger wrote:\n>>\n>>> Am Sonntag 11 Januar 2009 schrieb Christian Borntraeger:\n>>>> doing a \n>>>> git bisect start\n>>>> git bisect good a3a798c\n>>>> git bisect bad v2.6.29-rc1\n>>>>\n>>>> results in a repository without several files, e.g Makefile!\n>>>> git describe also fails.\n>>> In fact, retesting with a clean repository shows, that there are only \n> btrfs \n>>> files - nothing else.\n>>>\n>>> Linus did you pull a broken btrfs repository?\n>> I guess it is a subtree merge. So no, nothing went wrong\n>>\n>> Use \"git bisect skip\" to skip over those.\n> \n> I think we should really avoid merging subtrees to the linux kernel. It makes \n> bisecting a real PITA. \n\nShould is too soft, we cannot. What if it changes mainline files, they will\nnot have common ancestry. And also the sub-tree checkout un-checkout will take\nages. Chris must have merged with his subtree with a rebase not a merge. I suspect\nLinus git tree will have to rebase. This is the first time I've seen such a merge.\nfor example see be0e5c097f it has no parent, and so on.\n\n> Furthermore, It is unlikely, but what if the problem is part of the 581 \n> changesets from btrfs?\n> \n\nExactly\n\n> Christian\n> --\n\nBoaz\n"},{"id":"99978","messageId":"alpine.LFD.2.00.0901111113150.6528@localhost.localdomain","threadId":"17087","inReplyTo":"200901111620.03345.borntraeger@de.ibm.com","subject":"Re: current git kernel has strange problems during bisect","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-01-11T19:13:30Z","receivedAt":"2009-01-11T19:13:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOn Sun, 11 Jan 2009, Christian Borntraeger wrote:\n> \n> I think we should really avoid merging subtrees to the linux kernel. It \n> makes bisecting a real PITA. Furthermore, It is unlikely, but what if \n> the problem is part of the 581 changesets from btrfs?\n\nUmm, yes? \n\nThe thing is, btrfs was developed as an outside module. There are two \nchoices: import it with history, or import it without history. The history \nis interesting, so importing _with_ it is a much nicer one. But that does \nmean that btrfs introduces into the kernel tree the same behaviour we've \nhad in the git development tree for a long time - multiple root commits, \nand \"independent\" branches that get merged.\n\nIt's actually very natural for git, and the btrfs tree actually was \nre-done with \"git filter-branch\" to move all the history so that it is in \nfs/btrfs, rather than moving around from the root like the _original_ \ndevelopment was done. So it's not technically a subtree merge, it's a \nregular merge with just two different root commits - one for the original \nbase kernel development, one for the original btrfs kernel development.\n\nFor bisect, it's indeed somewhat annoying, and we could have perhaps done \nsome things a bit differently, but it's about the closest you can get to \n\"real history\" without making the first btrfs merge-point a _total_ \ndisaster.\n\nFor bisect purposes, if you know you're not chasing down a btrfs issue, \nyou can do\n\n\tgit bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8\n\nwhere that commit 34353029 is the last one which has _just_ the btrfs \nfiles. The next commit is when it does \"Merge Btrfs into fs/btrfs\", and \nthat one has the whole kernel tree again.\n\n\t\t\tLinus\n"},{"id":"99980","messageId":"20090111194258.GA4840@uranus.ravnborg.org","threadId":"17087","inReplyTo":"alpine.LFD.2.00.0901111113150.6528@localhost.localdomain","subject":"Re: current git kernel has strange problems during bisect","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2009-01-11T19:42:58Z","receivedAt":"2009-01-11T19:42:58Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"> \n> For bisect, it's indeed somewhat annoying, and we could have perhaps done \n> some things a bit differently, but it's about the closest you can get to \n> \"real history\" without making the first btrfs merge-point a _total_ \n> disaster.\n> \n> For bisect purposes, if you know you're not chasing down a btrfs issue, \n> you can do\n> \n> \tgit bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8\n> \n> where that commit 34353029 is the last one which has _just_ the btrfs \n> files. The next commit is when it does \"Merge Btrfs into fs/btrfs\", and \n> that one has the whole kernel tree again.\n\nThe cost of moving this piece of history from one git tree to another\ngit tree is that we make it harder to debug the kernel for the advanced user\nthat knows how to do bisect.\n\nIt is not like this history would be lost - one just had to look\nsomewhere else to find it.\n\nThat may be a bad pain/benefit ratio - time will tell.\n\nThere should be a way to avoid such pain when bisecting without\nhaving to mark a semi-random (for the average person) commit as good.\nAs in something that is present when the average bisect user pull the tree,\nand not something the user has to do afterwards.\n\n\tSam\n"},{"id":"99982","messageId":"f19298770901111147t625a2161t779bfcfc0317225c@mail.gmail.com","threadId":"17087","inReplyTo":"20090111194258.GA4840@uranus.ravnborg.org","subject":"Re: current git kernel has strange problems during bisect","fromName":"Alexey Zaytsev","fromEmail":"alexey.zaytsev@gmail.com","sentAt":"2009-01-11T19:47:18Z","receivedAt":"2009-01-11T19:47:18Z","isPatch":false,"sender":{"key":"alexey.zaytsev@gmail.com","avatar":"https://gravatar.com/avatar/111ff2626bafc25e0477f25f915a4ea4651fe1c29d9512f631092800e4426acd?d=mp&s=160"},"body":"On Sun, Jan 11, 2009 at 22:42, Sam Ravnborg wrote:\n>>\n>> For bisect, it's indeed somewhat annoying, and we could have perhaps done\n>> some things a bit differently, but it's about the closest you can get to\n>> \"real history\" without making the first btrfs merge-point a _total_\n>> disaster.\n>>\n>> For bisect purposes, if you know you're not chasing down a btrfs issue,\n>> you can do\n>>\n>> git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8\n>>\n>> where that commit 34353029 is the last one which has _just_ the btrfs\n>> files. The next commit is when it does \"Merge Btrfs into fs/btrfs\", and\n>> that one has the whole kernel tree again.\n>\n> The cost of moving this piece of history from one git tree to another\n> git tree is that we make it harder to debug the kernel for the advanced user\n> that knows how to do bisect.\n\nAnd wasn't is trivial to avoid? Just exporting the commits as\npatches and importing them into the kernel tree would preserve\nthe history, and not break bisection.\n"},{"id":"99989","messageId":"alpine.LFD.2.00.0901111200330.6528@localhost.localdomain","threadId":"17087","inReplyTo":"20090111194258.GA4840@uranus.ravnborg.org","subject":"Re: current git kernel has strange problems during bisect","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-01-11T20:04:12Z","receivedAt":"2009-01-11T20:04:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 11 Jan 2009, Sam Ravnborg wrote:\n> \n> The cost of moving this piece of history from one git tree to another\n> git tree is that we make it harder to debug the kernel for the advanced user\n> that knows how to do bisect.\n> \n> It is not like this history would be lost - one just had to look\n> somewhere else to find it.\n> \n> That may be a bad pain/benefit ratio - time will tell.\n\nUmm. No. \n\nTime is exactly what makes it useful. It will make all the downsides \nshrink, and the advantages stay.\n\n> There should be a way to avoid such pain when bisecting without\n> having to mark a semi-random (for the average person) commit as good.\n\nWell, you don't actually have to mark that semi-random one as good either. \nWhat you can do is to just mark anything that _only_ contains fs/btrfs as \ngood. IOW, you don't have to know the magic number - you just have to be \ntold that \"oh, if you only have btrfs files, and you're not actively \nbisecting a btrfs bug, just do 'git bisect good' and continue\".\n\nYeah, you'll hit it a few times, but you don't even have to compile things \nor boot anything, so it's not actually going to be all that much slower \nthan just knowing about the magic point either.\n\nSo now you can consider yourself told how to solve it. It wasn't that \nhard. And the advantage is that we have real history.\n\n\t\t\tLinus\n"},{"id":"100000","messageId":"87tz85fuxr.fsf@basil.nowhere.org","threadId":"17087","inReplyTo":"alpine.LFD.2.00.0901111113150.6528@localhost.localdomain","subject":"Re: current git kernel has strange problems during bisect","fromName":"Andi Kleen","fromEmail":"andi@firstfloor.org","sentAt":"2009-01-11T20:29:20Z","receivedAt":"2009-01-11T20:29:20Z","isPatch":false,"sender":{"key":"andi@firstfloor.org","avatar":null},"body":"Linus Torvalds writes:\n>\n> For bisect purposes, if you know you're not chasing down a btrfs issue, \n> you can do\n>\n> \tgit bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8\n\nCould you perhaps add some standard tag for that commit? That \nwould make it easier than to always find the exact btrfs commit.\n\nJust an idea.\n\n-Andi\n\n-- \nak@linux.intel.com\n"},{"id":"100003","messageId":"alpine.DEB.1.00.0901112150110.3586@pacific.mpi-cbg.de","threadId":"17087","inReplyTo":"87tz85fuxr.fsf@basil.nowhere.org","subject":"Re: current git kernel has strange problems during bisect","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-11T20:51:21Z","receivedAt":"2009-01-11T20:51:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Jan 2009, Andi Kleen wrote:\n\n> Linus Torvalds writes:\n> >\n> > For bisect purposes, if you know you're not chasing down a btrfs issue, \n> > you can do\n> >\n> > \tgit bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8\n> \n> Could you perhaps add some standard tag for that commit? That \n> would make it easier than to always find the exact btrfs commit.\n> \n> Just an idea.\n\nWell, AFAICT what Linus hinted at is that you do not need such a standard \ntag. Indeed, you would only clutter the history with such tags, when it \nusually is just a matter of saying \"git bisect good\" whenever you _know_ \nyou are hitting known-good history.\n\nCiao,\nDscho\n"},{"id":"100009","messageId":"200901112239.20306.borntraeger@de.ibm.com","threadId":"17087","inReplyTo":"alpine.LFD.2.00.0901111200330.6528@localhost.localdomain","subject":"Re: current git kernel has strange problems during bisect","fromName":"Christian Borntraeger","fromEmail":"borntraeger@de.ibm.com","sentAt":"2009-01-11T21:39:20Z","receivedAt":"2009-01-11T21:39:20Z","isPatch":false,"sender":{"key":"borntraeger@de.ibm.com","avatar":null},"body":"Am Sonntag 11 Januar 2009 schrieb Linus Torvalds:\n> Well, you don't actually have to mark that semi-random one as good either. \n> What you can do is to just mark anything that _only_ contains fs/btrfs as \n> good. IOW, you don't have to know the magic number - you just have to be \n> told that \"oh, if you only have btrfs files, and you're not actively \n> bisecting a btrfs bug, just do 'git bisect good' and continue\".\n\nThat should work.\n\n\nStill, I am a bit frustrated. During this weekend I reported 2 regressions \n(wlan and ata) and I still try to find out why suspend/resume stopped \nworking. In the meantime I have identified 2 patches (one was already known, \nI reported the 2nd to the usb maintainers) after 2.6.28 that caused suspend \nto ram regressions. In rc1 S2R was broken again. So I tried bisecting the \nthird patch - which finally brought me to the btrfs bisect problem.\n\nFor me, this was the most annoying merge window ever.\n\nIn my opinion we should really avoid subtree merges in the future as a curtesy \nto people who do the uncool work of testing, problem tracking and bisecting. \n\n\nChristian\n"},{"id":"100010","messageId":"20090111215454.GA6019@uranus.ravnborg.org","threadId":"17087","inReplyTo":"alpine.LFD.2.00.0901111200330.6528@localhost.localdomain","subject":"Re: current git kernel has strange problems during bisect","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2009-01-11T21:54:54Z","receivedAt":"2009-01-11T21:54:54Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"On Sun, Jan 11, 2009 at 12:04:12PM -0800, Linus Torvalds wrote:\n> \n> \n> On Sun, 11 Jan 2009, Sam Ravnborg wrote:\n> > \n> > The cost of moving this piece of history from one git tree to another\n> > git tree is that we make it harder to debug the kernel for the advanced user\n> > that knows how to do bisect.\n> > \n> > It is not like this history would be lost - one just had to look\n> > somewhere else to find it.\n> > \n> > That may be a bad pain/benefit ratio - time will tell.\n> \n> Umm. No. \n> \n> Time is exactly what makes it useful. It will make all the downsides \n> shrink, and the advantages stay.\n> \n> > There should be a way to avoid such pain when bisecting without\n> > having to mark a semi-random (for the average person) commit as good.\n> \n> Well, you don't actually have to mark that semi-random one as good either. \n> What you can do is to just mark anything that _only_ contains fs/btrfs as \n> good. IOW, you don't have to know the magic number - you just have to be \n> told that \"oh, if you only have btrfs files, and you're not actively \n> bisecting a btrfs bug, just do 'git bisect good' and continue\".\n\nAnd we lost 24 hours due to timezone differences etc. and maybe\na few testers.\nThats my point.\n\nThere are other obvious ways to do this where we keep history in kernel\nbut do not impact bisect.\nAnd we have one frustrated tester already - so this is not a made up example.\n\n\tSam\n"},{"id":"100013","messageId":"f19298770901111417t6762e1e3x79b2f488ee6f1243@mail.gmail.com","threadId":"17087","inReplyTo":"alpine.LFD.2.00.0901111200330.6528@localhost.localdomain","subject":"Re: current git kernel has strange problems during bisect","fromName":"Alexey Zaytsev","fromEmail":"alexey.zaytsev@gmail.com","sentAt":"2009-01-11T22:17:31Z","receivedAt":"2009-01-11T22:17:31Z","isPatch":false,"sender":{"key":"alexey.zaytsev@gmail.com","avatar":"https://gravatar.com/avatar/111ff2626bafc25e0477f25f915a4ea4651fe1c29d9512f631092800e4426acd?d=mp&s=160"},"body":"On Sun, Jan 11, 2009 at 23:04, Linus Torvalds\n wrote:\n>\n>\n> On Sun, 11 Jan 2009, Sam Ravnborg wrote:\n>>\n>> The cost of moving this piece of history from one git tree to another\n>> git tree is that we make it harder to debug the kernel for the advanced user\n>> that knows how to do bisect.\n>>\n>> It is not like this history would be lost - one just had to look\n>> somewhere else to find it.\n>>\n>> That may be a bad pain/benefit ratio - time will tell.\n>\n> Umm. No.\n>\n> Time is exactly what makes it useful. It will make all the downsides\n> shrink, and the advantages stay.\n>\n>> There should be a way to avoid such pain when bisecting without\n>> having to mark a semi-random (for the average person) commit as good.\n>\n> Well, you don't actually have to mark that semi-random one as good either.\n> What you can do is to just mark anything that _only_ contains fs/btrfs as\n> good. IOW, you don't have to know the magic number - you just have to be\n> told that \"oh, if you only have btrfs files, and you're not actively\n> bisecting a btrfs bug, just do 'git bisect good' and continue\".\n>\n> Yeah, you'll hit it a few times, but you don't even have to compile things\n> or boot anything, so it's not actually going to be all that much slower\n> than just knowing about the magic point either.\n\nBut would not such bug avoid being bisected if you blindly\nmark btrfs commits as good?\n\nv2.6.29 <-- bad\n...\n...\n...\nbtrfs stuff <-- mark as good\n...\nthe-real-bug\n...\nv2.6.28 <-- good\n\nSo you hit the btrfs commit, mark it as good, leaving the real bug below,\nand the bisection continues, with both sides being actually bad.\n\nAm I missing something?\n"},{"id":"100020","messageId":"alpine.LNX.1.00.0901111646040.19665@iabervon.org","threadId":"17087","inReplyTo":"200901112239.20306.borntraeger@de.ibm.com","subject":"Re: current git kernel has strange problems during bisect","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-01-11T22:27:01Z","receivedAt":"2009-01-11T22:27:01Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 11 Jan 2009, Christian Borntraeger wrote:\n\n> Am Sonntag 11 Januar 2009 schrieb Linus Torvalds:\n> > Well, you don't actually have to mark that semi-random one as good either. \n> > What you can do is to just mark anything that _only_ contains fs/btrfs as \n> > good. IOW, you don't have to know the magic number - you just have to be \n> > told that \"oh, if you only have btrfs files, and you're not actively \n> > bisecting a btrfs bug, just do 'git bisect good' and continue\".\n> \n> That should work.\n> \n> \n> Still, I am a bit frustrated. During this weekend I reported 2 regressions \n> (wlan and ata) and I still try to find out why suspend/resume stopped \n> working. In the meantime I have identified 2 patches (one was already known, \n> I reported the 2nd to the usb maintainers) after 2.6.28 that caused suspend \n> to ram regressions. In rc1 S2R was broken again. So I tried bisecting the \n> third patch - which finally brought me to the btrfs bisect problem.\n> \n> For me, this was the most annoying merge window ever.\n> \n> In my opinion we should really avoid subtree merges in the future as a curtesy \n> to people who do the uncool work of testing, problem tracking and bisecting. \n> \n\nI think hitting a version without the actual kernel source in it should \nactually make bisecting easier, not harder; you can say without even \nbuilding the kernel that that version doesn't have the problem you're \ntrying to find, because it doesn't have anything in it.\n\nThe alternative to having that part of the tree empty would be to stick in \nsome kernel version there (probably 2.6.28), and then you'd build and test \n2.6.28 again, completely wasting a bunch of time.\n\nProbably the bisect documentation or messages need to make it clear what \nyou should do when you land on this sort of commit.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"100021","messageId":"20090111223215.GA6296@uranus.ravnborg.org","threadId":"17087","inReplyTo":"f19298770901111417t6762e1e3x79b2f488ee6f1243@mail.gmail.com","subject":"Re: current git kernel has strange problems during bisect","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2009-01-11T22:32:15Z","receivedAt":"2009-01-11T22:32:15Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"On Mon, Jan 12, 2009 at 01:17:31AM +0300, Alexey Zaytsev wrote:\n> On Sun, Jan 11, 2009 at 23:04, Linus Torvalds\n> wrote:\n> >\n> >\n> > On Sun, 11 Jan 2009, Sam Ravnborg wrote:\n> >>\n> >> The cost of moving this piece of history from one git tree to another\n> >> git tree is that we make it harder to debug the kernel for the advanced user\n> >> that knows how to do bisect.\n> >>\n> >> It is not like this history would be lost - one just had to look\n> >> somewhere else to find it.\n> >>\n> >> That may be a bad pain/benefit ratio - time will tell.\n> >\n> > Umm. No.\n> >\n> > Time is exactly what makes it useful. It will make all the downsides\n> > shrink, and the advantages stay.\n> >\n> >> There should be a way to avoid such pain when bisecting without\n> >> having to mark a semi-random (for the average person) commit as good.\n> >\n> > Well, you don't actually have to mark that semi-random one as good either.\n> > What you can do is to just mark anything that _only_ contains fs/btrfs as\n> > good. IOW, you don't have to know the magic number - you just have to be\n> > told that \"oh, if you only have btrfs files, and you're not actively\n> > bisecting a btrfs bug, just do 'git bisect good' and continue\".\n> >\n> > Yeah, you'll hit it a few times, but you don't even have to compile things\n> > or boot anything, so it's not actually going to be all that much slower\n> > than just knowing about the magic point either.\n> \n> But would not such bug avoid being bisected if you blindly\n> mark btrfs commits as good?\n> \n> v2.6.29 <-- bad\n> ...\n> ...\n> ...\n> btrfs stuff <-- mark as good\n> ...\n> the-real-bug\n> ...\n> v2.6.28 <-- good\n> \n> So you hit the btrfs commit, mark it as good, leaving the real bug below,\n> and the bisection continues, with both sides being actually bad.\n> \n> Am I missing something?\n\nYep - you miss that people get confused when suddenly they have no kernel source.\n\n\tSam\n"},{"id":"100022","messageId":"alpine.LNX.1.00.0901111727510.19665@iabervon.org","threadId":"17087","inReplyTo":"f19298770901111417t6762e1e3x79b2f488ee6f1243@mail.gmail.com","subject":"Re: current git kernel has strange problems during bisect","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-01-11T22:34:51Z","receivedAt":"2009-01-11T22:34:51Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 12 Jan 2009, Alexey Zaytsev wrote:\n\n> On Sun, Jan 11, 2009 at 23:04, Linus Torvalds\n> wrote:\n> >\n> >\n> > On Sun, 11 Jan 2009, Sam Ravnborg wrote:\n> >>\n> >> The cost of moving this piece of history from one git tree to another\n> >> git tree is that we make it harder to debug the kernel for the advanced user\n> >> that knows how to do bisect.\n> >>\n> >> It is not like this history would be lost - one just had to look\n> >> somewhere else to find it.\n> >>\n> >> That may be a bad pain/benefit ratio - time will tell.\n> >\n> > Umm. No.\n> >\n> > Time is exactly what makes it useful. It will make all the downsides\n> > shrink, and the advantages stay.\n> >\n> >> There should be a way to avoid such pain when bisecting without\n> >> having to mark a semi-random (for the average person) commit as good.\n> >\n> > Well, you don't actually have to mark that semi-random one as good either.\n> > What you can do is to just mark anything that _only_ contains fs/btrfs as\n> > good. IOW, you don't have to know the magic number - you just have to be\n> > told that \"oh, if you only have btrfs files, and you're not actively\n> > bisecting a btrfs bug, just do 'git bisect good' and continue\".\n> >\n> > Yeah, you'll hit it a few times, but you don't even have to compile things\n> > or boot anything, so it's not actually going to be all that much slower\n> > than just knowing about the magic point either.\n> \n> But would not such bug avoid being bisected if you blindly\n> mark btrfs commits as good?\n> \n> v2.6.29 <-- bad\n> ...\n> ...\n> ...\n> btrfs stuff <-- mark as good\n> ...\n> the-real-bug\n> ...\n> v2.6.28 <-- good\n> \n> So you hit the btrfs commit, mark it as good, leaving the real bug below,\n> and the bisection continues, with both sides being actually bad.\n> \n> Am I missing something?\n\nYes, there are no kernel bugs below the btrfs stuff, because there's no \nkernel at all below the btrfs stuff. The history is actually like:\n\nA -- B -- C -- D -- G\n /\n F -- E\n\nF and E are the btrfs stuff, while A-D and G are commit containing the \nkernel source (D and G also containing btrfs). Marking E as good cuts off \nF, but doesn't cut off anything at all on the top line. Of course, if \nyou're actually debugging a problem with btrfs that you somehow know to \nhave worked while btrfs was a separate module at so point, you would want \nto get into this history (and would build it as a separate module in order \nto do so).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"100028","messageId":"20090111230240.GA27489@artemis.corp","threadId":"17087","inReplyTo":"f19298770901111147t625a2161t779bfcfc0317225c@mail.gmail.com","subject":"Re: current git kernel has strange problems during bisect","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2009-01-11T23:02:40Z","receivedAt":"2009-01-11T23:02:40Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Jan 11, 2009 at 07:47:18PM +0000, Alexey Zaytsev wrote:\n> On Sun, Jan 11, 2009 at 22:42, Sam Ravnborg wrote:\n> >>\n> >> For bisect, it's indeed somewhat annoying, and we could have perhaps done\n> >> some things a bit differently, but it's about the closest you can get to\n> >> \"real history\" without making the first btrfs merge-point a _total_\n> >> disaster.\n> >>\n> >> For bisect purposes, if you know you're not chasing down a btrfs issue,\n> >> you can do\n> >>\n> >> git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8\n> >>\n> >> where that commit 34353029 is the last one which has _just_ the btrfs\n> >> files. The next commit is when it does \"Merge Btrfs into fs/btrfs\", and\n> >> that one has the whole kernel tree again.\n> >\n> > The cost of moving this piece of history from one git tree to another\n> > git tree is that we make it harder to debug the kernel for the advanced user\n> > that knows how to do bisect.\n> \n> And wasn't is trivial to avoid? Just exporting the commits as\n> patches and importing them into the kernel tree would preserve\n> the history, and not break bisection.\n\nAnd would have brought a whole history of totally irrelevant stuff that\nnever exited for real, with probably a lot of non-compiling sub-steps\nwhich would be even worse.\n\nNo, the two possible choices were to squash the whole stuff at once, or\ndo what has been done IMNSHO. People have to grok how to take shortcuts\nwith git-bisect. I know that git-bisect puts people on the brainless\ncourse of actions where they git-bisect; configure; compile; boot; test;\nmark as good/bad and retry. And that's what I sometimes don't like with\nit. Because people trust git-bisect too much and forget how to think\nright.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"100068","messageId":"200901120551.56791.chriscool@tuxfamily.org","threadId":"17087","inReplyTo":"20090111230240.GA27489@artemis.corp","subject":"Re: current git kernel has strange problems during bisect","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-01-12T04:51:56Z","receivedAt":"2009-01-12T04:51:56Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le lundi 12 janvier 2009, Pierre Habouzit a écrit :\n> On Sun, Jan 11, 2009 at 07:47:18PM +0000, Alexey Zaytsev wrote:\n> > On Sun, Jan 11, 2009 at 22:42, Sam Ravnborg wrote:\n> > >> For bisect, it's indeed somewhat annoying, and we could have perhaps\n> > >> done some things a bit differently, but it's about the closest you\n> > >> can get to \"real history\" without making the first btrfs merge-point\n> > >> a _total_ disaster.\n> > >>\n> > >> For bisect purposes, if you know you're not chasing down a btrfs\n> > >> issue, you can do\n> > >>\n> > >> git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8\n> > >>\n> > >> where that commit 34353029 is the last one which has _just_ the\n> > >> btrfs files. The next commit is when it does \"Merge Btrfs into\n> > >> fs/btrfs\", and that one has the whole kernel tree again.\n> > >\n> > > The cost of moving this piece of history from one git tree to another\n> > > git tree is that we make it harder to debug the kernel for the\n> > > advanced user that knows how to do bisect.\n> >\n> > And wasn't is trivial to avoid? Just exporting the commits as\n> > patches and importing them into the kernel tree would preserve\n> > the history, and not break bisection.\n>\n> And would have brought a whole history of totally irrelevant stuff that\n> never exited for real, with probably a lot of non-compiling sub-steps\n> which would be even worse.\n>\n> No, the two possible choices were to squash the whole stuff at once, or\n> do what has been done IMNSHO. People have to grok how to take shortcuts\n> with git-bisect. I know that git-bisect puts people on the brainless\n> course of actions where they git-bisect; configure; compile; boot; test;\n> mark as good/bad and retry. And that's what I sometimes don't like with\n> it. Because people trust git-bisect too much and forget how to think\n> right.\n\nWell \"git bisect\" can be more usefull if it can be fully automated (with git \nbisect run) because then you can make the computer do all the boring work. \nSo I think putting people on the \"brainless course of actions\" can often be \na good thing.\n\nAnyway it looks to me that this kind of problem could be avoided if one \ncould \"replace\" some commits only when bisecting. In this case what could \nbe done is that one could \"replace\" the commit where btrfs is merged with \none commit that cuts off the btrfs history. If the merge commit is only \nreplaced when bisecting, then you get the best of both worlds:\n\n_ when you bisect, you don't see the btrfs history that breaks the kernel \nbuild,\n_ when you don't bisect, you see the full real history.\n\nOf course if the bisection process finds out that the \"replaced\" commit is \nthe culprit, then you need to understand what this means...\n\nRegards,\nChristian.\n"},{"id":"100069","messageId":"200901120603.03977.chriscool@tuxfamily.org","threadId":"17087","inReplyTo":"200901120551.56791.chriscool@tuxfamily.org","subject":"Re: current git kernel has strange problems during bisect","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-01-12T05:03:03Z","receivedAt":"2009-01-12T05:03:03Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"I wrote:\n>\n> Anyway it looks to me that this kind of problem could be avoided if one\n> could \"replace\" some commits only when bisecting. In this case what could\n> be done is that one could \"replace\" the commit where btrfs is merged with\n> one commit that cuts off the btrfs history.\n\nBy the way, it possible right now to cut off the btrfs history in one's own \nrepository using a graft. One don't need to wait for me to finish the \nreplace stuff I am slowly working on. But on the other hand it will have \nall the restrictions of the current graft mechanism.\n\nRegards,\nChristian.\n"},{"id":"100310","messageId":"f73f7ab80901131226s6af7730cucf9c44bc2b4f9545@mail.gmail.com","threadId":"17087","inReplyTo":"200901112239.20306.borntraeger@de.ibm.com","subject":"Re: current git kernel has strange problems during bisect","fromName":"Kyle Moffett","fromEmail":"kyle@moffetthome.net","sentAt":"2009-01-13T20:26:09Z","receivedAt":"2009-01-13T20:26:09Z","isPatch":false,"sender":{"key":"kyle@moffetthome.net","avatar":null},"body":"On Sun, Jan 11, 2009 at 4:39 PM, Christian Borntraeger\n wrote:\n> In my opinion we should really avoid subtree merges in the future as a curtesy\n> to people who do the uncool work of testing, problem tracking and bisecting.\n> \n\nAs an alternative, you can relatively easily rewrite the following\nindependent histories:\n\nA -- B -- C\nX -- Y -- Z\n\nTo look like this:\n\nA -- B -- C -- X' -- Y' -- Z'\n\nWhere X' is (C + sub/dir/X), Y' is (C + sub/dir/Y), etc...\n\nAssuming the following:\n \"master\" branch points to commit C\n \"child\" branch points to commit Z\n \"${KIDSTART}\" is the SHA1 id of commit X\n\necho \"${KIDSTART} $(git rev-parse --verify master)\" >>.git/info/grafts\n\ngit filter-branch --index-filter 'git read-tree master && git\nread-tree --prefix=\"sub/dir/\" \"${GIT_COMMIT}\"' -- master..child\n\nThe one downside is then somebody actually has to *test* those commits\nwhen doing a bisect, even though they did not materially change\nanything. The upside is that there isn't any \"what the hell just\nhappened?\" when you *do* end up in the newly-created branch.\n\nCheers,\nKyle Moffett\n"},{"id":"100637","messageId":"20090115165425.GA7517@bombe-desk.opditex","threadId":"17087","inReplyTo":"f73f7ab80901131226s6af7730cucf9c44bc2b4f9545@mail.gmail.com","subject":"Re: current git kernel has strange problems during bisect","fromName":"Andreas Bombe","fromEmail":"andreas.bombe@mytum.de","sentAt":"2009-01-15T16:54:25Z","receivedAt":"2009-01-15T16:54:25Z","isPatch":false,"sender":{"key":"andreas.bombe@mytum.de","avatar":null},"body":"On Tue, Jan 13, 2009 at 03:26:09PM -0500, Kyle Moffett wrote:\n> On Sun, Jan 11, 2009 at 4:39 PM, Christian Borntraeger\n> wrote:\n> > In my opinion we should really avoid subtree merges in the future as a curtesy\n> > to people who do the uncool work of testing, problem tracking and bisecting.\n> > \n> \n> As an alternative, you can relatively easily rewrite the following\n> independent histories:\n> \n> A -- B -- C\n> X -- Y -- Z\n> \n> To look like this:\n> \n> A -- B -- C -- X' -- Y' -- Z'\n> \n> Where X' is (C + sub/dir/X), Y' is (C + sub/dir/Y), etc...\n\nGiven that the subtree may have been in development for a long time, it\nis almost a certainty that the older commits may compile on A but not\non C. By basing it all on C you create a lot of uncompilable commits\nwhich hurt bisection just as bad. At least with missing kernel sources\nit is obvious that an attempt at compilation is futile and a waste of\ntime.\n"},{"id":"100673","messageId":"f73f7ab80901151513l22b6b017gadb49312ac331391@mail.gmail.com","threadId":"17087","inReplyTo":"20090115165425.GA7517@bombe-desk.opditex","subject":"Re: current git kernel has strange problems during bisect","fromName":"Kyle Moffett","fromEmail":"kyle@moffetthome.net","sentAt":"2009-01-15T23:13:30Z","receivedAt":"2009-01-15T23:13:30Z","isPatch":false,"sender":{"key":"kyle@moffetthome.net","avatar":null},"body":"On Thu, Jan 15, 2009 at 11:54 AM, Andreas Bombe wrote:\n> On Tue, Jan 13, 2009 at 03:26:09PM -0500, Kyle Moffett wrote:\n>> On Sun, Jan 11, 2009 at 4:39 PM, Christian Borntraeger\n>> wrote:\n>> > In my opinion we should really avoid subtree merges in the future as a curtesy\n>> > to people who do the uncool work of testing, problem tracking and bisecting.\n>> > \n>>\n>> As an alternative, you can relatively easily rewrite the following\n>> independent histories:\n>>\n>> A -- B -- C\n>> X -- Y -- Z\n>>\n>> To look like this:\n>>\n>> A -- B -- C -- X' -- Y' -- Z'\n>>\n>> Where X' is (C + sub/dir/X), Y' is (C + sub/dir/Y), etc...\n>\n> Given that the subtree may have been in development for a long time, it\n> is almost a certainty that the older commits may compile on A but not\n> on C. By basing it all on C you create a lot of uncompilable commits\n> which hurt bisection just as bad. At least with missing kernel sources\n> it is obvious that an attempt at compilation is futile and a waste of\n> time.\n\nNo, the older commits will compile just fine as they don't actually\nreference the new code from any of the parent makefiles. It would\neffectively be \"dead code\" until the \"merge\" in the commit *after* Z'\nin which you add lines to \"sub/Kconfig\" and \"sub/Kbuild\" which\nreference \"sub/dir/*\".\n\nCheers,\nKyle Moffett\n"}]}