{"thread":{"id":"41096","subject":"Feature request: git bisect merge to usable base","startedAt":"2015-12-30T10:40:12Z","lastAt":"2016-01-04T22:38:40Z","messageCount":7,"participants":["Andy Lutomirski","Christian Couder","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"275175","messageId":"CALCETrUgsawpwkkjO_BpPHyOaH7NsJNU-4mF97a6NAxCMB5aUA@mail.gmail.com","threadId":"41096","inReplyTo":null,"subject":"Feature request: git bisect merge to usable base","fromName":"Andy Lutomirski","fromEmail":"luto@kernel.org","sentAt":"2015-12-30T10:40:12Z","receivedAt":"2015-12-30T10:40:12Z","isPatch":false,"sender":{"key":"luto@kernel.org","avatar":null},"body":"Hi-\n\nI'm currently bisecting a Linux bug on my laptop. The starting good\ncommit is v4.4-rc3 and the starting bad commit is v4.4-rc7.\nUnfortunately, anything much older than v4.4-rc3 doesn't boot at all.\n\nI'd like to say:\n\n$ git bisect merge-to v4.4-rc3\n\nor similar. The effect would be that, rather than testing commits in\nbetween the good and bad commits, it would test the result of merging\nthose commits with v4.4-rc3.\n\nObviously the syntax could be tweaked a lot, but I think the concept\ncould be quite handy.\n\nThanks,\nAndy\n"},{"id":"275191","messageId":"CAP8UFD3vc+gZtPpWKgFug1NUXc3WzPFwtoNaZLiNiW5oW-WAqA@mail.gmail.com","threadId":"41096","inReplyTo":"CALCETrUgsawpwkkjO_BpPHyOaH7NsJNU-4mF97a6NAxCMB5aUA@mail.gmail.com","subject":"Re: Feature request: git bisect merge to usable base","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2015-12-30T18:54:45Z","receivedAt":"2015-12-30T18:54:45Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Wed, Dec 30, 2015 at 11:40 AM, Andy Lutomirski wrote:\n> Hi-\n>\n> I'm currently bisecting a Linux bug on my laptop. The starting good\n> commit is v4.4-rc3 and the starting bad commit is v4.4-rc7.\n> Unfortunately, anything much older than v4.4-rc3 doesn't boot at all.\n>\n> I'd like to say:\n>\n> $ git bisect merge-to v4.4-rc3\n>\n> or similar. The effect would be that, rather than testing commits in\n> between the good and bad commits, it would test the result of merging\n> those commits with v4.4-rc3.\n>\n> Obviously the syntax could be tweaked a lot, but I think the concept\n> could be quite handy.\n\nThere have been talks about bisecting on the first parents and I think\nit would be useful in your case.\nAfter bisecting on the first parents you would know which merged\nbranch is responsible for the bug and you could for example rebase it\non top of v4.4-rc3 and then bisect on it.\n\nYou may find some scripts that might help you by searching for \"bisect\nfirst parent\", like maybe there:\n\nhttp://stackoverflow.com/questions/20240526/how-to-git-bisect-only-on-one-branchs-commits\n\nOr maybe some old patchs on this list.\n\nBest,\nChristian.\n"},{"id":"275195","messageId":"xmqqsi2jem15.fsf@gitster.mtv.corp.google.com","threadId":"41096","inReplyTo":"CALCETrUgsawpwkkjO_BpPHyOaH7NsJNU-4mF97a6NAxCMB5aUA@mail.gmail.com","subject":"Re: Feature request: git bisect merge to usable base","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-30T20:09:26Z","receivedAt":"2015-12-30T20:09:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Lutomirski writes:\n\n> I'm currently bisecting a Linux bug on my laptop. The starting good\n> commit is v4.4-rc3 and the starting bad commit is v4.4-rc7.\n> Unfortunately, anything much older than v4.4-rc3 doesn't boot at all.\n>\n> I'd like to say:\n>\n> $ git bisect merge-to v4.4-rc3\n>\n> or similar. The effect would be that, rather than testing commits in\n> between the good and bad commits, it would test the result of merging\n> those commits with v4.4-rc3.\n>\n> Obviously the syntax could be tweaked a lot, but I think the concept\n> could be quite handy.\n\nI do not think such an option or \"concept\" belongs to \"git bisect\".\n\nWhen \"git bisect\" checks out a commit to test, it is entirely up to\nyou how to decide if the commit is good or bad. Your example is to\nwork on the Linux kernel project, so the way to test might be \"make\nmrproper && make bzImage && ... && reboot\" to see if the result\nboots.\n\nThere is nothing that prevents you from changing the test procedure\nto be prefixed by \"if the version to test is older than version X,\nmerge the commit to version X first before doing anything else\".\n\nThe key thing to realize is that \"merge the version X\" is not\nuniversally useful \"fixup\" to deal with unbuildable or untestable\ncommit. In some situations, \"I have this fix-up patch I need to\napply for versions that are older than Y before I can test\" may be a\nlot more appropriate \"fixup\". So \"merge-to\" does not deserve to be\nthe first-class \"concept\".\n\n\"Here is a script to fix up the tree that 'git bisect' tells me to\ntest\" instead might be a general enough concept, and you might say\n\n\t$ git bisect --fixup \"./my-fixup-script\"\n\nand have \"git merge --no-commit v4.4-rc3\" in \"my-fixup-script\",\nperhaps.\n\nBut at that point, it would be as easy as adding whatever you would\nwrite in my-fixup-script at the beginning of the script you are\nalready using (and if you aren't, read up on \"git bisect run\") to\nperform the test. So...\n"},{"id":"275313","messageId":"CALCETrUO2Gx9vRqkGLaGWLsuMs98k5d3PKEPfx3RZf4+fpko4Q@mail.gmail.com","threadId":"41096","inReplyTo":"xmqqsi2jem15.fsf@gitster.mtv.corp.google.com","subject":"Re: Feature request: git bisect merge to usable base","fromName":"Andy Lutomirski","fromEmail":"luto@amacapital.net","sentAt":"2016-01-04T18:15:11Z","receivedAt":"2016-01-04T18:15:11Z","isPatch":false,"sender":{"key":"luto@amacapital.net","avatar":null},"body":"On Wed, Dec 30, 2015 at 12:09 PM, Junio C Hamano wrote:\n> Andy Lutomirski writes:\n>\n>> I'm currently bisecting a Linux bug on my laptop. The starting good\n>> commit is v4.4-rc3 and the starting bad commit is v4.4-rc7.\n>> Unfortunately, anything much older than v4.4-rc3 doesn't boot at all.\n>>\n>> I'd like to say:\n>>\n>> $ git bisect merge-to v4.4-rc3\n>>\n>> or similar. The effect would be that, rather than testing commits in\n>> between the good and bad commits, it would test the result of merging\n>> those commits with v4.4-rc3.\n>>\n>> Obviously the syntax could be tweaked a lot, but I think the concept\n>> could be quite handy.\n>\n> I do not think such an option or \"concept\" belongs to \"git bisect\".\n>\n> When \"git bisect\" checks out a commit to test, it is entirely up to\n> you how to decide if the commit is good or bad. Your example is to\n> work on the Linux kernel project, so the way to test might be \"make\n> mrproper && make bzImage && ... && reboot\" to see if the result\n> boots.\n>\n> There is nothing that prevents you from changing the test procedure\n> to be prefixed by \"if the version to test is older than version X,\n> merge the commit to version X first before doing anything else\".\n>\n> The key thing to realize is that \"merge the version X\" is not\n> universally useful \"fixup\" to deal with unbuildable or untestable\n> commit. In some situations, \"I have this fix-up patch I need to\n> apply for versions that are older than Y before I can test\" may be a\n> lot more appropriate \"fixup\". So \"merge-to\" does not deserve to be\n> the first-class \"concept\".\n>\n> \"Here is a script to fix up the tree that 'git bisect' tells me to\n> test\" instead might be a general enough concept, and you might say\n>\n> $ git bisect --fixup \"./my-fixup-script\"\n>\n> and have \"git merge --no-commit v4.4-rc3\" in \"my-fixup-script\",\n> perhaps.\n>\n> But at that point, it would be as easy as adding whatever you would\n> write in my-fixup-script at the beginning of the script you are\n> already using (and if you aren't, read up on \"git bisect run\") to\n> perform the test. So...\n\ngit bisect run is great, but it's not so great when the test process\nis \"sudo make modules_install && sudo make install && reboot\", then\nboot new kernel, then run emacs, then see if it worked... There\ndoesn't appear to be a 'git bisect run' option to pause and wait for\nan explicit user request to continue, unfortunately.\n\n--Andy\n"},{"id":"275322","messageId":"xmqqa8olnl1r.fsf@gitster.mtv.corp.google.com","threadId":"41096","inReplyTo":"CALCETrUO2Gx9vRqkGLaGWLsuMs98k5d3PKEPfx3RZf4+fpko4Q@mail.gmail.com","subject":"Re: Feature request: git bisect merge to usable base","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-04T20:31:44Z","receivedAt":"2016-01-04T20:31:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Lutomirski writes:\n\n> git bisect run is great, but it's not so great when the test process\n> is \"sudo make modules_install && sudo make install && reboot\", then\n> boot new kernel, then run emacs, then see if it worked... There\n> doesn't appear to be a 'git bisect run' option to pause and wait for\n> an explicit user request to continue, unfortunately.\n\nThat is expected to be part of your run script, as that is a custom\nand specialized need your bisection has.\n\nIt still will not work when the test procedure involves rebooting,\nbut \"git bisect\" does not require you to install and reboot the same\nmachine you are running the bisection on, i.e. the test process\ncould be \"build && scp there && ssh there reboot && see if comes up\"\n;-)\n"},{"id":"275330","messageId":"CALCETrV_JAEbuU3v+V352_8PVyaB1noGQAfJG+HVVanVpUbRZw@mail.gmail.com","threadId":"41096","inReplyTo":"xmqqa8olnl1r.fsf@gitster.mtv.corp.google.com","subject":"Re: Feature request: git bisect merge to usable base","fromName":"Andy Lutomirski","fromEmail":"luto@amacapital.net","sentAt":"2016-01-04T22:20:50Z","receivedAt":"2016-01-04T22:20:50Z","isPatch":false,"sender":{"key":"luto@amacapital.net","avatar":null},"body":"On Mon, Jan 4, 2016 at 12:31 PM, Junio C Hamano wrote:\n> Andy Lutomirski writes:\n>\n>> git bisect run is great, but it's not so great when the test process\n>> is \"sudo make modules_install && sudo make install && reboot\", then\n>> boot new kernel, then run emacs, then see if it worked... There\n>> doesn't appear to be a 'git bisect run' option to pause and wait for\n>> an explicit user request to continue, unfortunately.\n>\n> That is expected to be part of your run script, as that is a custom\n> and specialized need your bisection has.\n>\n> It still will not work when the test procedure involves rebooting,\n> but \"git bisect\" does not require you to install and reboot the same\n> machine you are running the bisection on, i.e. the test process\n> could be \"build && scp there && ssh there reboot && see if comes up\"\n> ;-)\n>\n\nAll I'm going for is simplicity. I was bisecting on my laptop, and I\ncouldn't reproduce on a VM, so I wasn't going to use 'git bisect run',\nbecause git bisect run doesn't support my use case.\n\nAnyway, the idea of merging test commits up to some lowest common\ndenominator seems generally useful to me, and the idea of specifying a\n'prepare the checked-out tree' (as you suggested, where 'git merge\n--no-commit whatever' would be specified) would also be handy, and\nboth of these are useful even in cases where git bisect run isn't\nbeing used.\n\n--Andy\n"},{"id":"275331","messageId":"xmqqfuydm0lr.fsf@gitster.mtv.corp.google.com","threadId":"41096","inReplyTo":"CALCETrV_JAEbuU3v+V352_8PVyaB1noGQAfJG+HVVanVpUbRZw@mail.gmail.com","subject":"Re: Feature request: git bisect merge to usable base","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-04T22:38:40Z","receivedAt":"2016-01-04T22:38:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Lutomirski writes:\n\n> Anyway, the idea of merging test commits up to some lowest common\n> denominator seems generally useful to me, and the idea of specifying a\n> 'prepare the checked-out tree' (as you suggested, where 'git merge\n> --no-commit whatever' would be specified) would also be handy, and\n> both of these are useful even in cases where git bisect run isn't\n> being used.\n\nYes, I didn't mean to say \"bisect run\" is always great. What I was\nhinting at was that even if you are _not_ using \"bisect run\" (which\nalmost always _requires_ you to write a small script that does the\ntest and says yes/no), once you start working on a project that is\nsufficiently complex (like bisecting a regression in the Linux\nkernel), your procedure to build and test a single revision becomes\ncomplex enough that it is worth to write and use a small script for\na single step _anyway_. And with that in mind, \"how do I prepare\nthe checked-out tree for building and testing\" can be part of that\nscript.\n\nWhich in turn means there is nothing to add to \"bisect\", not even\nthe \"--fixup my_fixup_script\" I alluded to, let alone \"--merge-to\"\nthat is way too specific to the case you happened to have had before\nyou sent your message.\n"}]}