Re: Feature request: git bisect merge to usable base

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 30, 2015 at 12:09 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Andy Lutomirski <luto@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]