git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Feature request: git bisect merge to usable base

From
ALAndy Lutomirski <luto@amacapital.net>
Date
Jan 4, 2016, 18:15 UTC
Message-ID
<CALCETrUO2Gx9vRqkGLaGWLsuMs98k5d3PKEPfx3RZf4+fpko4Q@mail.gmail.com>
In-Reply-To
<xmqqsi2jem15.fsf@gitster.mtv.corp.google.com>
On Wed, Dec 30, 2015 at 12:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 48 quoted lines
> 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
Previous: Junio C HamanoNext: Junio C Hamano
Message 4 of 7 in “Feature request: git bisect merge to usable base”
  1. Andy LutomirskiDec 30, 2015
  2. Christian CouderDec 30, 2015
  3. Junio C HamanoDec 30, 2015
  4. Andy LutomirskiJan 4, 2016
  5. Junio C HamanoJan 4, 2016
  6. Andy LutomirskiJan 4, 2016
  7. Junio C HamanoJan 4, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.