Re: Feature request: git bisect merge to usable base
On Mon, Jan 4, 2016 at 12:31 PM, Junio C Hamanowrote: > Andy Lutomirski writes: > >> git bisect run is great, but it's not so great when the test process >> is "sudo make modules_install && sudo make install && reboot", then >> boot new kernel, then run emacs, then see if it worked... There >> doesn't appear to be a 'git bisect run' option to pause and wait for >> an explicit user request to continue, unfortunately. > > That is expected to be part of your run script, as that is a custom > and specialized need your bisection has. > > It still will not work when the test procedure involves rebooting, > but "git bisect" does not require you to install and reboot the same > machine you are running the bisection on, i.e. the test process > could be "build && scp there && ssh there reboot && see if comes up" > ;-) > All I'm going for is simplicity. I was bisecting on my laptop, and I couldn't reproduce on a VM, so I wasn't going to use 'git bisect run', because git bisect run doesn't support my use case. Anyway, the idea of merging test commits up to some lowest common denominator seems generally useful to me, and the idea of specifying a 'prepare the checked-out tree' (as you suggested, where 'git merge --no-commit whatever' would be specified) would also be handy, and both of these are useful even in cases where git bisect run isn't being used. --Andy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: git bisect merge to usable base
Andy Lutomirskiwrites: > Anyway, the idea of merging test commits up to some lowest common > denominator seems generally useful to me, and the idea of specifying a > 'prepare the checked-out tree' (as you suggested, where 'git merge > --no-commit whatever' would be specified) would also be handy, and > both of these are useful even in cases where git bisect run isn't > being used. Yes, I didn't mean to say "bisect run" is always great. What I was hinting at was that even if you are _not_ using "bisect run" (which almost always _requires_ you to write a small script that does the test and says yes/no), once you start working on a project that is sufficiently complex (like bisecting a regression in the Linux kernel), your procedure to build and test a single revision becomes complex enough that it is worth to write and use a small script for a single step _anyway_. And with that in mind, "how do I prepare the checked-out tree for building and testing" can be part of that script. Which in turn means there is nothing to add to "bisect", not even the "--fixup my_fixup_script" I alluded to, let alone "--merge-to" that is way too specific to the case you happened to have had before you sent your message. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: git bisect merge to usable base
On Wed, Dec 30, 2015 at 12:09 PM, Junio C Hamanowrote: > Andy Lutomirski writes: > >> I'm currently bisecting a Linux bug on my laptop. The starting good >> commit is v4.4-rc3 and the starting bad commit is v4.4-rc7. >> Unfortunately, anything much older than v4.4-rc3 doesn't boot at all. >> >> I'd like to say: >> >> $ git bisect merge-to v4.4-rc3 >> >> or similar. The effect would be that, rather than testing commits in >> between the good and bad commits, it would test the result of merging >> those commits with v4.4-rc3. >> >> Obviously the syntax could be tweaked a lot, but I think the concept >> could be quite handy. > > I do not think such an option or "concept" belongs to "git bisect". > > When "git bisect" checks out a commit to test, it is entirely up to > you how to decide if the commit is good or bad. Your example is to > work on the Linux kernel project, so the way to test might be "make > mrproper && make bzImage && ... && reboot" to see if the result > boots. > > There is nothing that prevents you from changing the test procedure > to be prefixed by "if the version to test is older than version X, > merge the commit to version X first before doing anything else". > > The key thing to realize is that "merge the version X" is not > universally useful "fixup" to deal with unbuildable or untestable > commit. In some situations, "I have this fix-up patch I need to > apply for versions that are older than Y before I can test" may be a > lot more appropriate "fixup". So "merge-to" does not deserve to be > the first-class "concept". > > "Here is a script to fix up the tree that 'git bisect' tells me to > test" instead might be a general enough concept, and you might say > > $ git bisect --fixup "./my-fixup-script" > > and have "git merge --no-commit v4.4-rc3" in "my-fixup-script", > perhaps. > > But at that point, it would be as easy as adding whatever you would > write in my-fixup-script at the beginning of the script you are > already using (and if you aren't, read up on "git bisect run") to > perform the test. So... git bisect run is great, but it's not so great when the test process is "sudo make modules_install && sudo make install && reboot", then boot new kernel, then run emacs, then see if it worked... There doesn't appear to be a 'git bisect run' option to pause and wait for an explicit user request to continue, unfortunately. --Andy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: git bisect merge to usable base
Andy Lutomirskiwrites: > I'm currently bisecting a Linux bug on my laptop. The starting good > commit is v4.4-rc3 and the starting bad commit is v4.4-rc7. > Unfortunately, anything much older than v4.4-rc3 doesn't boot at all. > > I'd like to say: > > $ git bisect merge-to v4.4-rc3 > > or similar. The effect would be that, rather than testing commits in > between the good and bad commits, it would test the result of merging > those commits with v4.4-rc3. > > Obviously the syntax could be tweaked a lot, but I think the concept > could be quite handy. I do not think such an option or "concept" belongs to "git bisect". When "git bisect" checks out a commit to test, it is entirely up to you how to decide if the commit is good or bad. Your example is to work on the Linux kernel project, so the way to test might be "make mrproper && make bzImage && ... && reboot" to see if the result boots. There is nothing that prevents you from changing the test procedure to be prefixed by "if the version to test is older than version X, merge the commit to version X first before doing anything else". The key thing to realize is that "merge the version X" is not universally useful "fixup" to deal with unbuildable or untestable commit. In some situations, "I have this fix-up patch I need to apply for versions that are older than Y before I can test" may be a lot more appropriate "fixup". So "merge-to" does not deserve to be the first-class "concept". "Here is a script to fix up the tree that 'git bisect' tells me to test" instead might be a general enough concept, and you might say $ git bisect --fixup "./my-fixup-script" and have "git merge --no-commit v4.4-rc3" in "my-fixup-script", perhaps. But at that point, it would be as easy as adding whatever you would write in my-fixup-script at the beginning of the script you are already using (and if you aren't, read up on "git bisect run") to perform the test. So... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: git bisect merge to usable base
Hi, On Wed, Dec 30, 2015 at 11:40 AM, Andy Lutomirskiwrote: > Hi- > > I'm currently bisecting a Linux bug on my laptop. The starting good > commit is v4.4-rc3 and the starting bad commit is v4.4-rc7. > Unfortunately, anything much older than v4.4-rc3 doesn't boot at all. > > I'd like to say: > > $ git bisect merge-to v4.4-rc3 > > or similar. The effect would be that, rather than testing commits in > between the good and bad commits, it would test the result of merging > those commits with v4.4-rc3. > > Obviously the syntax could be tweaked a lot, but I think the concept > could be quite handy. There have been talks about bisecting on the first parents and I think it would be useful in your case. After bisecting on the first parents you would know which merged branch is responsible for the bug and you could for example rebase it on top of v4.4-rc3 and then bisect on it. You may find some scripts that might help you by searching for "bisect first parent", like maybe there: http://stackoverflow.com/questions/20240526/how-to-git-bisect-only-on-one-branchs-commits Or maybe some old patchs on this list. Best, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Feature request: git bisect merge to usable base
Hi- I'm currently bisecting a Linux bug on my laptop. The starting good commit is v4.4-rc3 and the starting bad commit is v4.4-rc7. Unfortunately, anything much older than v4.4-rc3 doesn't boot at all. I'd like to say: $ git bisect merge-to v4.4-rc3 or similar. The effect would be that, rather than testing commits in between the good and bad commits, it would test the result of merging those commits with v4.4-rc3. Obviously the syntax could be tweaked a lot, but I think the concept could be quite handy. Thanks, Andy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html