{"thread":{"id":"42161","subject":"Bisect limited to Merge Commits","startedAt":"2016-04-27T20:45:51Z","lastAt":"2016-04-28T06:44:23Z","messageCount":6,"participants":["Hagen Paul Pfeifer","Junio C Hamano","Johannes Sixt","Jacob Keller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"284743","messageId":"20160427204551.GB4613@virgo.localdomain","threadId":"42161","inReplyTo":null,"subject":"Bisect limited to Merge Commits","fromName":"Hagen Paul Pfeifer","fromEmail":"hagen@jauu.net","sentAt":"2016-04-27T20:45:51Z","receivedAt":"2016-04-27T20:45:51Z","isPatch":false,"sender":{"key":"hagen@jauu.net","avatar":null},"body":"Hey,\n\nare there any plans to add an option to skip all non-merge commits via\nbisecting?\n\ngit bisect start --merges-only\n\nImagine a \"rebase feature branch\" style of development. All features are\ndeveloped on separate features branch which are rebased on master and\nimmediately merged into the upstream master. Now think about lazy programmers\nwho miss to check the build process at each commit - leading to many\nunbuildable commits. The only guaranteed buildable commit is often the merge\ncommit.\n\nBisecting only merge commits will reduce the amount of skip commands (think\nabout many unbuildable commits) and reduce the number of tests.\n\nAny comments on this idea? What about extending bisect.c:do_find_bisection()\n\n\n\thgn\n"},{"id":"284746","messageId":"xmqq8tzy93ed.fsf@gitster.mtv.corp.google.com","threadId":"42161","inReplyTo":"20160427204551.GB4613@virgo.localdomain","subject":"Re: Bisect limited to Merge Commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-27T20:56:42Z","receivedAt":"2016-04-27T20:56:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Hagen Paul Pfeifer <hagen@jauu.net> writes:\n\n> Imagine a \"rebase feature branch\" style of development. All features are\n> developed on separate features branch which are rebased on master and\n> immediately merged into the upstream master. \n\nI do not want to imagine such ;-)  The only semi-sensible reason why\npeople might want to always rebase on top of 'master' is to keep the\nhistory completely linear, so with such a workflow, there won't be a\nmerge commit.\n\nBut I think \"rebase\" part of your description is a red herring.  If\na development goes by always doing a new feature in a side branch\nand then merge the branch only after it is done to the 'master'\nbranch, then bisecting only the commits on first-parent chain would\noften be a quick first-pass to find the topic whose merge into the\n'master' branch introduced a breakage.  From there you can dig down\nto each individual commit on the side branch.  And for that, it is\nimmaterial that the side branch gets rebased on 'master' and forced\nto become a merge with \"--no-ff\", of the side branch was developed\non older upstream but in a careless way full of \"oops, previous one\nI broke the entire world and it does not even compile; this commit\nfixes it\" commits.\n\nSo being able to stop at only commits on the first-parent chain is a\nvalid and useful tool.  \"git bisect --first-parent\" is one of the\nthings that are sometimes asked for.\n"},{"id":"284753","messageId":"57213041.5070506@kdbg.org","threadId":"42161","inReplyTo":"xmqq8tzy93ed.fsf@gitster.mtv.corp.google.com","subject":"Re: Bisect limited to Merge Commits","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-04-27T21:33:53Z","receivedAt":"2016-04-27T21:33:53Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 27.04.2016 um 22:56 schrieb Junio C Hamano:\n> So being able to stop at only commits on the first-parent chain is a\n> valid and useful tool.  \"git bisect --first-parent\" is one of the\n> things that are sometimes asked for.\n\nWith origin pointing to git.git, I attempted this:\n\n  git bisect start\n  git rev-list --first-parent --boundary origin..origin/pu |\n    sed -ne s/-//p | xargs git bisect good\n  git bisect bad origin/pu\n\nand it starts bisecting among the 50-something first-parent commits \nbetween origin and origin/pu.\n\n-- Hannes\n"},{"id":"284757","messageId":"xmqqk2ji7kpr.fsf@gitster.mtv.corp.google.com","threadId":"42161","inReplyTo":"57213041.5070506@kdbg.org","subject":"Re: Bisect limited to Merge Commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-27T22:25:36Z","receivedAt":"2016-04-27T22:25:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j6t@kdbg.org> writes:\n\n> Am 27.04.2016 um 22:56 schrieb Junio C Hamano:\n>> So being able to stop at only commits on the first-parent chain is a\n>> valid and useful tool.  \"git bisect --first-parent\" is one of the\n>> things that are sometimes asked for.\n>\n> With origin pointing to git.git, I attempted this:\n>\n>  git bisect start\n>  git rev-list --first-parent --boundary origin..origin/pu |\n>    sed -ne s/-//p | xargs git bisect good\n>  git bisect bad origin/pu\n>\n> and it starts bisecting among the 50-something first-parent commits\n> between origin and origin/pu.\n\nThat is a cute idea but I wonder if it would work well in a history\nfull of pointless no-ff merges.\n\nHere is a sample topology (output from \"git log --oneline --graph\")\n\n    *   84ef1bb pointless\n    |\\  \n    | * 4ae9f68 third\n    |/  \n    *   aec8732 pointless\n    |\\  \n    | * fd4ed0d second\n    |/  \n    * 696b5c1 initial\n\nwhere the tip of 'master' was initial, a side branch built 'second'\non it and then 'master' made a no-ff 'pointless' merge, another side\nbranch built 'third' on it and then 'master' again made a no-ff\n'pointless' merge.\n\n    $ git rev-list --first-parent --boundary initial..pointless\n\nwould give us 'third' and 'second' as boundaries, but by marking\n'third' as GOOD, we declare to 'bisect' machinery that it and all of\nits ancestors are GOOD.  So upon seeing 'bisect bad HEAD', we would\nimmediately see that HEAD is the first bad commit, wouldn't we?\n\nActually, \"pointless no-ff merges\" is a red herring.  Any history\nwith side branch that branched from the first-parent chain after the\ncommit at the bottom of the bisection range (in this example, the\nside branch that built 'third' was forked off of the first 'pointless'\ncommit on the first-parent chain of 'master', which was made after\nthe bottom of the range 'initial') would have the same problem, I\nwould imagine.\n"},{"id":"284768","messageId":"20160428061929.GA11322@virgo.localdomain","threadId":"42161","inReplyTo":"57213041.5070506@kdbg.org","subject":"Re: Bisect limited to Merge Commits","fromName":"Hagen Paul Pfeifer","fromEmail":"hagen@jauu.net","sentAt":"2016-04-28T06:19:30Z","receivedAt":"2016-04-28T06:19:30Z","isPatch":false,"sender":{"key":"hagen@jauu.net","avatar":null},"body":"* Johannes Sixt | 2016-04-27 23:33:53 [+0200]:\n\nHey Junio, hey Hannes,\n\n> git bisect start\n> git rev-list --first-parent --boundary origin..origin/pu |\n>   sed -ne s/-//p | xargs git bisect good\n> git bisect bad origin/pu\n>\n>and it starts bisecting among the 50-something first-parent commits between\n>origin and origin/pu.\n\njust for clarification: contributors rebase their work before pushing it on\nmaster. The integrator simple merges --no-ff the individual branches. Just a\nregular workflow, nothing special - except that many contributor commits will\nnot build. ;(\n\nThe idea is just to skip the contributor commits during bisect and focus on\nthe merge commits (the ones with more than one ancestors) because they are\nlikely build and testable.\n\nOne possible approach is probably to sort out all non-merge commits before\nbisecting and bisect only on a this set of commits. The advantage is that the\nfirst bad commit is the merge commit introduced the regression. Mmmh, any\ncomments?\n\nhgn\n"},{"id":"284774","messageId":"CA+P7+xq-g3JPxKROa9Ne0EGiSgSqHKgqVG3eoW9Q-dP0yPOrVA@mail.gmail.com","threadId":"42161","inReplyTo":"20160428061929.GA11322@virgo.localdomain","subject":"Re: Bisect limited to Merge Commits","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-04-28T06:44:23Z","receivedAt":"2016-04-28T06:44:23Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Apr 27, 2016 at 11:19 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:\n> * Johannes Sixt | 2016-04-27 23:33:53 [+0200]:\n>\n> Hey Junio, hey Hannes,\n>\n>> git bisect start\n>> git rev-list --first-parent --boundary origin..origin/pu |\n>>   sed -ne s/-//p | xargs git bisect good\n>> git bisect bad origin/pu\n>>\n>>and it starts bisecting among the 50-something first-parent commits between\n>>origin and origin/pu.\n>\n> just for clarification: contributors rebase their work before pushing it on\n> master. The integrator simple merges --no-ff the individual branches. Just a\n> regular workflow, nothing special - except that many contributor commits will\n> not build. ;(\n>\n> The idea is just to skip the contributor commits during bisect and focus on\n> the merge commits (the ones with more than one ancestors) because they are\n> likely build and testable.\n>\n> One possible approach is probably to sort out all non-merge commits before\n> bisecting and bisect only on a this set of commits. The advantage is that the\n> first bad commit is the merge commit introduced the regression. Mmmh, any\n> comments?\n>\n\nI suspect doing something akin to the idea of \"bisect --first-parent\"\nwould work for this use case and be more flexible in general. Your\nidea is pretty much what i think bisect --first-parent would do,\nexcept that it would also work for non-merge commits which happen to\nbe in the \"mainline\" history.\n\nThanks,\nJake\n"}]}