{"thread":{"id":"21325","subject":"git bisect Vs branch","startedAt":"2009-10-22T15:48:59Z","lastAt":"2009-10-23T18:29:10Z","messageCount":7,"participants":["Grégory Romé","Santi Béjar","Johannes Sixt","Daniel Barkalow","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"125711","messageId":"4AE07EEB.2010101@maxim-ic.com","threadId":"21325","inReplyTo":null,"subject":"git bisect Vs branch","fromName":"Grégory Romé","fromEmail":"gregory.rome@maxim-ic.com","sentAt":"2009-10-22T15:48:59Z","receivedAt":"2009-10-22T15:48:59Z","isPatch":false,"sender":{"key":"gregory.rome@maxim-ic.com","avatar":null},"body":"Considering the following story what is the method to find the \nregression with bisect?\n\nI cloned a git repository (origin) which derives from another one \n(first-origin). A merge is done from first-origin to origin at each \nstable release (identified by a tag).\n\nfirst-origin/master *---A---------B-----------------------C-\n \\ \\ \\ \norigin/master ----------B'----------U-----------C'-\n \\ \\ \\ \nmaster ------------U'----------C''-\n\nNow, after that I merged C' I fixed the conflicts and compiled without \nerror but I have a regression. It could come from any commit between B \nand C or U and C', and I need to modify my code to correct the issue.\n\nI would like to find the commit which introduce this regression by using \ngit bisect but as the history is not linear it is not so easy (1). It \nthough to create a linear history but I have no idea how to proceed...\n\nThanks,\nGrégory\n\n(1) \nhttp://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bisect-merges\n"},{"id":"125713","messageId":"adf1fd3d0910220950s50ccf8efwda891374e6480a30@mail.gmail.com","threadId":"21325","inReplyTo":"4AE07EEB.2010101@maxim-ic.com","subject":"Re: git bisect Vs branch","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2009-10-22T16:50:30Z","receivedAt":"2009-10-22T16:50:30Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Thu, Oct 22, 2009 at 5:48 PM, Grégory Romé wrote:\n> Considering the following story what is the method to find the regression\n> with bisect?\n>\n> I cloned a git repository (origin) which derives from another one\n> (first-origin). A merge is done from first-origin to origin at each stable\n> release (identified by a tag).\n>\n> first-origin/master  *---A---------B-----------------------C-\n>                         \\         \\                       \\\n> origin/master              ----------B'----------U-----------C'-\n>                                     \\           \\           \\   master\n>                           ------------U'----------C''-\n>\n> Now, after that I merged C' I fixed the conflicts and compiled without error\n> but I have a regression. It could come from any commit between B and C or U\n> and C', and I need to modify my code to correct the issue.\n>\n> I would like to find the commit which introduce this regression by using git\n> bisect but as the history is not linear it is not so easy (1). It though to\n> create a linear history but I have no idea how to proceed...\n\nYou just have to proceed as normal, but you may test more commits than\nwith a linear history.\n\nThe only problem is iff the culprit is a merge commit (as in the\nuser-manual chapter you linked). And the \"problem\" is to know where\nexactly in the (merge) commit is the bug, but not the procedure.\n\nHTH,\nSanti\n"},{"id":"125775","messageId":"4AE156A9.9060809@maxim-ic.com","threadId":"21325","inReplyTo":"adf1fd3d0910220950s50ccf8efwda891374e6480a30@mail.gmail.com","subject":"Re: git bisect Vs branch","fromName":"Grégory Romé","fromEmail":"gregory.rome@maxim-ic.com","sentAt":"2009-10-23T07:09:29Z","receivedAt":"2009-10-23T07:09:29Z","isPatch":false,"sender":{"key":"gregory.rome@maxim-ic.com","avatar":null},"body":"Thanks Santi but I have a problem, due to the fact that the commit which has an \nimpact on my code is in origin/master or first-origin/master\n\nWhen bisect checkout a commit from those branch I have none of my own \nmodifications... So I can' test if my code is good or bad excepted if I can \nmerge my commits in the bisect branch...\n ᐁ\nfirst-origin/master *---A---------B----------------o------C-\n \\ \\ \\\norigin/master ----------B'----------U-----------C'-\n \\ \\ \\\nmaster ------------U'----------C''-\n\n\nI generalized the problem but I can give a real example. My problem concerns an \nLinux USB driver for MIPS based SoC. first-origin is the official kernel \nrepository and origin/master is the MIPS repository.\n\nCheers!\nGrégory\n\n\nSanti Béjar wrote:\n> On Thu, Oct 22, 2009 at 5:48 PM, Grégory Romé wrote:\n>> Considering the following story what is the method to find the regression\n>> with bisect?\n>>\n>> I cloned a git repository (origin) which derives from another one\n>> (first-origin). A merge is done from first-origin to origin at each stable\n>> release (identified by a tag).\n>>\n>> first-origin/master *---A---------B-----------------------C-\n>> \\ \\ \\\n>> origin/master ----------B'----------U-----------C'-\n>> \\ \\ \\ master\n>> ------------U'----------C''-\n>>\n>> Now, after that I merged C' I fixed the conflicts and compiled without error\n>> but I have a regression. It could come from any commit between B and C or U\n>> and C', and I need to modify my code to correct the issue.\n>>\n>> I would like to find the commit which introduce this regression by using git\n>> bisect but as the history is not linear it is not so easy (1). It though to\n>> create a linear history but I have no idea how to proceed...\n> \n> You just have to proceed as normal, but you may test more commits than\n> with a linear history.\n> \n> The only problem is iff the culprit is a merge commit (as in the\n> user-manual chapter you linked). And the \"problem\" is to know where\n> exactly in the (merge) commit is the bug, but not the procedure.\n> \n> HTH,\n> Santi\n"},{"id":"125778","messageId":"4AE16A82.1010103@viscovery.net","threadId":"21325","inReplyTo":"4AE156A9.9060809@maxim-ic.com","subject":"Re: git bisect Vs branch","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-10-23T08:34:10Z","receivedAt":"2009-10-23T08:34:10Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Grégory Romé schrieb:\n> Thanks Santi but I have a problem, due to the fact that the commit which\n> has an impact on my code is in origin/master or first-origin/master\n> \n> When bisect checkout a commit from those branch I have none of my own\n> modifications... So I can' test if my code is good or bad excepted if I\n> can merge my commits in the bisect branch...\n> ᐁ\n> first-origin/master *---A---------B----------------o------C-\n> \\ \\ \\\n> origin/master ----------B'----------U-----------C'-\n> \\ \\ \\\n> master ------------U'----------C''-\n\nC\" is the commit that merges upstream changes into your changes. You are\nsaying that your changes alone (before the merge) are good, and that\nupstream before the merge is also good (since it doesn't contain your\nchanges, it is good by definition, more or less). That indeed means that\nthe merge commit is the first bad one; i.e., this is exactly the situation\nthat the user manual describes.\n\nYou should do:\n\n $ git checkout -b tmp master # master is at C\"\n $ git rebase origin/master\n $ git bisect start tmp orgin/master\n\nThat is, you rebuild your history on top of origin/master in a linear\nfashion. (If you had merge conflicts in U', then you will see them again.)\nThen you bisect the linearized history. This will point you to the bad\ncommit and you will understand what is going wrong.\n\nWith this new knowledge, go back to master (C\") and fix the problem.\n\n-- Hannes\n"},{"id":"125784","messageId":"4AE17645.2000408@maxim-ic.com","threadId":"21325","inReplyTo":"4AE16A82.1010103@viscovery.net","subject":"Re: git bisect Vs branch","fromName":"Grégory Romé","fromEmail":"gregory.rome@maxim-ic.com","sentAt":"2009-10-23T09:24:21Z","receivedAt":"2009-10-23T09:24:21Z","isPatch":false,"sender":{"key":"gregory.rome@maxim-ic.com","avatar":null},"body":"Thanks even if that's what scared me :)\nThe draw is very simple comparing to the reality (much more merge points) and \nrebase will require lot of conflicts resolutions but now I'm sure that's what I \nhave to do.\n\nGrégory\n\nJohannes Sixt wrote:\n> Grégory Romé schrieb:\n>> Thanks Santi but I have a problem, due to the fact that the commit which\n>> has an impact on my code is in origin/master or first-origin/master\n>>\n>> When bisect checkout a commit from those branch I have none of my own\n>> modifications... So I can' test if my code is good or bad excepted if I\n>> can merge my commits in the bisect branch...\n>> ᐁ\n>> first-origin/master *---A---------B----------------o------C-\n>> \\ \\ \\\n>> origin/master ----------B'----------U-----------C'-\n>> \\ \\ \\\n>> master ------------U'----------C''-\n> \n> C\" is the commit that merges upstream changes into your changes. You are\n> saying that your changes alone (before the merge) are good, and that\n> upstream before the merge is also good (since it doesn't contain your\n> changes, it is good by definition, more or less). That indeed means that\n> the merge commit is the first bad one; i.e., this is exactly the situation\n> that the user manual describes.\n> \n> You should do:\n> \n> $ git checkout -b tmp master # master is at C\"\n> $ git rebase origin/master\n> $ git bisect start tmp orgin/master\n> \n> That is, you rebuild your history on top of origin/master in a linear\n> fashion. (If you had merge conflicts in U', then you will see them again.)\n> Then you bisect the linearized history. This will point you to the bad\n> commit and you will understand what is going wrong.\n> \n> With this new knowledge, go back to master (C\") and fix the problem.\n> \n> -- Hannes\n> \n"},{"id":"125792","messageId":"alpine.LNX.2.00.0910231137290.14365@iabervon.org","threadId":"21325","inReplyTo":"4AE17645.2000408@maxim-ic.com","subject":"Re: git bisect Vs branch","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-10-23T16:31:07Z","receivedAt":"2009-10-23T16:31:07Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 23 Oct 2009, Grégory Romé wrote:\n\n> Thanks even if that's what scared me :)\n> The draw is very simple comparing to the reality (much more merge points) and\n> rebase will require lot of conflicts resolutions but now I'm sure that's what\n> I have to do.\n\nAlternatively, you could say that your testing procedure is to merge with \nyour branch and check for the regression. Instead of bisecting U''-C'', \nbisect U'-C', but merge master (or rather, the first parent of the merge \nthat started not working) before testing each commit. Pose the problem as \nupstream having a regression in that it doesn't work when merged with your \ncode, and solve that problem with bisect.\n\nBut, before you start, verify that merging U'' and origin/master doesn't \nwork; if it does work, you recently introduced the change that doesn't \nwork with upstream, and it's probably a lot easier to find what you did \nthat's not okay any more than what made it not okay upstream. That is, \nmake C*; if it works, rebase your recent changes on it and debug that. \nThis should have fewer conflicts and be easier than the full rebase, if C* \nactually turns out to work:\n\nU'--o-o--C'\n \\ |\\\n U''-y-y--C''\n \\ |\n -----C*--y-y\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"125794","messageId":"7vd44ec6bt.fsf@alter.siamese.dyndns.org","threadId":"21325","inReplyTo":"4AE156A9.9060809@maxim-ic.com","subject":"Re: git bisect Vs branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-23T18:29:10Z","receivedAt":"2009-10-23T18:29:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Grégory Romé writes:\n\n> Thanks Santi but I have a problem, due to the fact that the commit\n> which has an impact on my code is in origin/master or\n> first-origin/master\n>\n> When bisect checkout a commit from those branch I have none of my own\n> modifications... So I can' test if my code is good or bad excepted if\n> I can merge my commits in the bisect branch...\n> ᐁ\n> first-origin/master *---A---------B----------------o------C-\n> \\ \\ \\\n> origin/master ----------B'----------U-----------C'-\n> \\ \\ \\\n> master ------------U'----------C''-\n>\n>\n> I generalized the problem but I can give a real example. My problem\n> concerns an Linux USB driver for MIPS based SoC. first-origin is the\n> official kernel repository and origin/master is the MIPS repository.\n\nSo the breakage is about the feature you added on your tree, which neither\nof the grandparent upstream nor your direct upstream has. U' worked, C''^1\n(i.e. immediately before you merged from your direct upstream at C'')\nworked, and C'' doesn't.\n\nThis happens when a commit in the upstream (either in your direct upstream\nor its upstream) changed the semantics of a function (or a variable's\nvalue) in such a way that it invalidates some assumption that your code\nhas been relying on.\n\nYou can restate the problem into a slightly different form:\n\n - If I merge C' to my master (C''^1), it breaks;\n\n - If I merge U to my master (C''^1), it works;\n\n - Starting from (U = good, C' = bad) pair, find the first \"bad\" commit,\n where the badness is defined as \"when it is merged to C''^1, it\n breaks\".\n\nThe restated problem is \"where in their code did they change something\nthat breaks my code?\"\n\nYou do not have to make a merge in the repository you are bisecting in.\nFor example, I would try something along this line:\n\n $ git clone . ../test-build ;# make a build directory\n $ M=$(git rev-parse master^1) ;# before the latest merge\n $ U=$(git merge-base $M origin/master)\n $ git bisect start\n $ git bisect bad origin/master\n $ git bisect good $U\n\nThis will check out one commit between U and C' (that will include commits\nbeetween B and C, as they are reachable from C' but not from U) for you to\ntest. Since the condition you are testing is \"Does the result of merging\na commit to $M work?\", you check exactly that condition:\n\n $ H=$(git rev-parse HEAD)\n $ cd ../test-build\n $ git reset --hard\n $ git checkout $M\n $ git merge $H\n ... do your testing here ...\n\nAnd go back to the repository you are bisecting, and tell the result to\nbisect to continue:\n\n $ cd -\n $ git bisect good ;# or bad\n\nAnd do the same for the next commit to be tested.\n\nThe result will tell you which commit in the upstream changed the\nsemantics of what you were relying on under you, and by examining that\nchange, hopefully you will know how to adjust your code to the new world\norder the upstream (re-)defines.\n"}]}