{"thread":{"id":"3231","subject":"git bisect and the merge from hell","startedAt":"2006-02-03T19:47:36Z","lastAt":"2006-02-03T20:58:14Z","messageCount":3,"participants":["Luck, Tony","Junio C Hamano","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15524","messageId":"200602031947.k13JlaDr003720@agluck-lia64.sc.intel.com","threadId":"3231","inReplyTo":null,"subject":"git bisect and the merge from hell","fromName":"Luck, Tony","fromEmail":"tony.luck@intel.com","sentAt":"2006-02-03T19:47:36Z","receivedAt":"2006-02-03T19:47:36Z","isPatch":false,"sender":{"key":"tony.luck@intel.com","avatar":"https://avatars.githubusercontent.com/u/5446021?v=4"},"body":"Sometime between -rc1 and -rc2 the ia64 kernel picked up a bug\nthat prevents booting a UP kernel on my workstation (I recycled\nthe serial cable to hook up a new machine, so I don't have the\nOOPS).\n\nSo I thought I'd use git bisect to narrow it down.  A few iterations\nin it picked the merge from hell, and two iterations after that it\nappears to have wandered into the weeds and picked something from\nbefore -rc1.\n\n $ git describe 3c5c363826e435cf4d54d917202567e5b57cae5f\n v2.6.15-g3c5c3638\n\nIs this normal?\n\nA couple of iterations down (with git bisect saying that we were into\nthe home stretch with only 5 commits to go) I ran into build problems,\nso I haven't yet got to the bottom of the problem).\n\nHere's the BISECT_LOG:\ngit-bisect start\n# bad: [826eeb53a6f264842200d3311d69107d2eb25f5e] Linux v2.6.16-rc2\ngit-bisect bad 826eeb53a6f264842200d3311d69107d2eb25f5e\n# good: [2664b25051f7ab96b22b199aa2f5ef6a949a4296] Linux v2.6.16-rc1\ngit-bisect good 2664b25051f7ab96b22b199aa2f5ef6a949a4296\n# good: [10379a25fee8ddc8698d2f6c54ccedd4664c2941] Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/agpgart\ngit-bisect good 10379a25fee8ddc8698d2f6c54ccedd4664c2941\n# good: [9a2dba4b4912b493070cbc170629fdbf440b01d7] slab: rename ac_data to cpu_cache_get\ngit-bisect good 9a2dba4b4912b493070cbc170629fdbf440b01d7\n# good: [9ad11ab48b1ad618bf47076e9e579f267f5306c2] compat: fix compat_sys_openat and friends\ngit-bisect good 9ad11ab48b1ad618bf47076e9e579f267f5306c2\n# good: [1494a92f4c2b1d5abdaa1f823dd19f797bb137de] [ALSA] hda-codec - Fix typos in alc882 model table\ngit-bisect good 1494a92f4c2b1d5abdaa1f823dd19f797bb137de\n# bad: [9fdb62af92c741addbea15545f214a6e89460865] [ACPI] merge 3549 4320 4485 4588 4980 5483 5651 acpica asus fops pnpacpi branches into release\ngit-bisect bad 9fdb62af92c741addbea15545f214a6e89460865\n# bad: [3c5c363826e435cf4d54d917202567e5b57cae5f] [ACPI] delete message \"**** SET: Misaligned resource pointer:\"\ngit-bisect bad 3c5c363826e435cf4d54d917202567e5b57cae5f\n# bad: [c51a4de85de720670f2fbc592a6f8040af72ad87] [ACPI] ACPICA 20051117\ngit-bisect bad c51a4de85de720670f2fbc592a6f8040af72ad87\n\nGit version is 1.1.4\n\n-Tony\n"},{"id":"15533","messageId":"7virrwdvv1.fsf@assigned-by-dhcp.cox.net","threadId":"3231","inReplyTo":"200602031947.k13JlaDr003720@agluck-lia64.sc.intel.com","subject":"Re: git bisect and the merge from hell","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-03T20:34:58Z","receivedAt":"2006-02-03T20:34:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Luck, Tony\" <tony.luck@intel.com> writes:\n\n> Sometime between -rc1 and -rc2 the ia64 kernel picked up a bug\n> that prevents booting a UP kernel on my workstation (I recycled\n> the serial cable to hook up a new machine, so I don't have the\n> OOPS).\n>\n> So I thought I'd use git bisect to narrow it down.  A few iterations\n> in it picked the merge from hell, and two iterations after that it\n> appears to have wandered into the weeds and picked something from\n> before -rc1.\n>\n>  $ git describe 3c5c363826e435cf4d54d917202567e5b57cae5f\n>  v2.6.15-g3c5c3638\n>\n> Is this normal?\n\nI haven't looked at your ancestry graph yet (I am at work\nwriting this message during my lunch break), but if one of the\nbranches merged between rc1 and rc2 were forked from the\nmainline at a commit before rc1, that is an expected behaviour.\nSuppose:\n\n       .o---o---o--- ... ---o---o.\n      /                           \\\n     /                             \\\n ---o---o---*---o--- ... ---o---o---*---o---o---*\n            rc1                     octopus     rc2\n\nAnd you said \"rc1 was OK but rc2 is BAD\".  Now, the bug may well\nbe somewhere between rc1 and Len's octopus on the lower\ndevelopment track.  But the problem may have been introduced by\nsome of the commits on the upper development track that bypassed\nrc1.  They are not descendant of rc1, and describe would say\nthey come after v2.6.15.\n\nThe side branch merged during that timeperiod that forked before\nrc1 may not be the one merged by Len's octopus but may be merged\nby some other merge, but the story is the same.\n"},{"id":"15537","messageId":"Pine.LNX.4.64.0602031246030.4630@g5.osdl.org","threadId":"3231","inReplyTo":"200602031947.k13JlaDr003720@agluck-lia64.sc.intel.com","subject":"Re: git bisect and the merge from hell","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-03T20:58:14Z","receivedAt":"2006-02-03T20:58:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 3 Feb 2006, Luck, Tony wrote:\n>\n> Sometime between -rc1 and -rc2 the ia64 kernel picked up a bug\n> that prevents booting a UP kernel on my workstation (I recycled\n> the serial cable to hook up a new machine, so I don't have the\n> OOPS).\n> \n> So I thought I'd use git bisect to narrow it down.  A few iterations\n> in it picked the merge from hell, and two iterations after that it\n> appears to have wandered into the weeds and picked something from\n> before -rc1.\n>\n>  $ git describe 3c5c363826e435cf4d54d917202567e5b57cae5f\n>  v2.6.15-g3c5c3638\n> \n> Is this normal?\n\nThat commit _is_ in between v2.6.16-rc1 and -r2:\n\n  [torvalds@g5 linux]$ git-rev-list v2.6.16-rc1..v2.6.16-rc2 | grep 3c5c363826e435\n  3c5c363826e435cf4d54d917202567e5b57cae5f\n\nbut it came through a merge, so the history isn't linear. That commit does \nnot actually ever reach 2.6.16-rc1 in its history.\n\nUse \"git bisect visualize\" to see what \"git bisect\" is doing. It's doing \neverything right so far..\n\n> A couple of iterations down (with git bisect saying that we were into\n> the home stretch with only 5 commits to go) I ran into build problems,\n> so I haven't yet got to the bottom of the problem).\n\nOk. That's a different issue. \n\nWhen you hit a problem where \"git bisect\" will pick a place that doesn't \ncompile (usually for some stupid reason that you're not at all \ninterested in chasing down), what you should do is\n\n\tgit bisect visualize\n\nto see what commits are interesting.\n\nThen, pick one of the interesting ones \"at random\" (it helps if it's not \nclose to any of the known-uninteresting points), and do\n\n\tgit reset --hard <picked-sha1>\n\nand try that instead (and compile that, and just continue with your \nbisection: mark it good or bad depending on whether it works).\n\nBasically, what you're doing is to override the choice of place to test \nthat \"git bisect\" chose automatically for you. It still works, but \nobviously the point is probably not as \"half-way\" any more, so it makes \nthe narrowing down of the bad commit slightly less efficient.\n\n> Here's the BISECT_LOG:\n\nOk, you've done great progress. You only have 11 revisions left to test \n(the last message would have been \"5 revisions left to test after this\", \nbut that means that _after_ you've verified the picked point, you'd have \nhad just five versions left.\n\n\"git bisect visualize\" really makes it very obvious what to try next, I \nthink. Which exact commit you try next probably depends on what the \ncompile error was. I'd try\n\n\tgit reset --hard 3d5271f9883cba7b54762bc4fe027d4172f06db7\n\n(which is after the \"pull release into acpica branch\" commit).\n\n\t\tLinus\n"}]}