Feature request: git bisect merge to usable base

Feature request: git bisect merge to usable base

[Andy Lutomirski]

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

Re: Feature request: git bisect merge to usable base

[Christian Couder]

Hi,

On Wed, Dec 30, 2015 at 11:40 AM, Andy Lutomirski <luto@kernel.org> wrote:
> 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.

Re: Feature request: git bisect merge to usable base

[Junio C Hamano]

Andy Lutomirski <luto@kernel.org> 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...

Re: Feature request: git bisect merge to usable base

[Andy Lutomirski]

On Wed, Dec 30, 2015 at 12:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Andy Lutomirski <luto@kernel.org> 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

Re: Feature request: git bisect merge to usable base

[Junio C Hamano]

Andy Lutomirski <luto@amacapital.net> 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"
;-)

Re: Feature request: git bisect merge to usable base

[Andy Lutomirski]

On Mon, Jan 4, 2016 at 12:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Andy Lutomirski <luto@amacapital.net> 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

Re: Feature request: git bisect merge to usable base

[Junio C Hamano]

Andy Lutomirski <luto@amacapital.net> writes:

> 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.