{"thread":{"id":"3234","subject":"RE: git bisect and the merge from hell","startedAt":"2006-02-03T23:16:58Z","lastAt":"2006-02-03T23:44:01Z","messageCount":2,"participants":["Luck, Tony","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15539","messageId":"B8E391BBE9FE384DAA4C5C003888BE6F059F4AF6@scsmsx401.amr.corp.intel.com","threadId":"3234","inReplyTo":null,"subject":"RE: git bisect and the merge from hell","fromName":"Luck, Tony","fromEmail":"tony.luck@intel.com","sentAt":"2006-02-03T23:16:58Z","receivedAt":"2006-02-03T23:16:58Z","isPatch":false,"sender":{"key":"tony.luck@intel.com","avatar":"https://avatars.githubusercontent.com/u/5446021?v=4"},"body":"> \"git bisect visualize\" really makes it very obvious what to try next, I \n> think. Which exact commit you try next probably depends on what the \n> compile error was. I'd try\n>\n>\tgit reset --hard 3d5271f9883cba7b54762bc4fe027d4172f06db7\n>\n> (which is after the \"pull release into acpica branch\" commit).\n\nYup, that got the bisection moving again.  I finished up at:\n\n$ git bisect bad\n96db255c8f014ae3497507104e8df809785a619f is first bad commit\ndiff-tree 96db255c8f014ae3497507104e8df809785a619f (from 0897831bb54eb36fd9e2a22da7f0f64be1b20d09)\nAuthor: Bob Moore <robert.moore@intel.com>\nDate:   Wed Nov 2 00:00:00 2005 -0500\n\n    [ACPI] ACPICA 20051102\n\nSo Len's mega-octopus merge wasn't a problem at all, but this is still\nall his fault :-)  I'll go beat on him.\n\nThanks for the tip.\n\n-Tony\n"},{"id":"15540","messageId":"Pine.LNX.4.64.0602031531440.3969@g5.osdl.org","threadId":"3234","inReplyTo":"B8E391BBE9FE384DAA4C5C003888BE6F059F4AF6@scsmsx401.amr.corp.intel.com","subject":"RE: git bisect and the merge from hell","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-03T23:44:01Z","receivedAt":"2006-02-03T23:44:01Z","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> So Len's mega-octopus merge wasn't a problem at all, but this is still\n> all his fault :-)  I'll go beat on him.\n\nNote that this _can_ be a problem with huge octopus merges.\n\nIf some bug only appears as a result of the interaction of two branches, \ndoing a 12-way merge will make it harder to debug. Doing a \"git bisect\" \nwill (correctly) pinpoint the merge as being the problem, but after that \nyou're on your own as to how to debug it.\n\nSo _if_ it had been a merge error, there's two issues with that:\n\n - debugging merges is usually a bit less straightforward than debugging a \n   single well-defined changeset anyway.\n\n - especially an octopus-merge will cause \"git-bisect\" to be less \n   efficient, since it cannot be bisected, so if the bug is in the merge \n   itself, it will ask you to test _every_ _single_ top-of-branch before \n   the merge.\n\n(Normally, testing 12 kernels would zoom in on a bug from 10.000 feet, and \nyou'd have bisected a massive four-thousand commits. So having to test 12 \nbranch heads just to pinpoint a _single_ commit is \"unusually expensive\" \nby any standard for git bisection).\n\nAnyway, had it been a merge bug, you should then have done:\n\n - check if it's simply a mis-merge. Do \"git-diff-tree --cc\" to see if \n   there were any conflicts, and check them out more closely to see \n   if maybe they were incorrectly fixed up.\n\n   Normally, an octopus merge will never have any actual _manual_ \n   conflicts (the standard git tools shouldn't allow it), but there can \n   still be several branches that touch the same area and that could have \n   merged strangely.\n\nIf that doesn't get you anywhere, you'll literally have to go to the next \nstep:\n\n - re-do the merges one by one, until the bug appears, or, if it's not \n   there once you've re-done them all, check what the differences are \n   (there _should_ be none, but see above on doing mis-merging) with the \n   final octopus one.\n\nAnyway, for \"normal\" bugs (like this one apparently is), git-bisect \nshouldn't ever pinpoint a merge, since the bug hopefully was introduced \nsomewhere _during_ the branch development, and not when it was merged \nback. Hopefully.\n\nAnyway. The message you should take home from this is that \"git bisect\" \nhandles merges perfectly well, and that at worst it might be less \nefficient and harder to debug - especially for octopus merges - but that \nboth of those problems are likely (a) rare and (b) not insurmountable.\n\n\t\tLinus\n"}]}