From: Junio C Hamano <gitster@pobox.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: git@vger.kernel.org
Subject: Re: Feature request: git bisect merge to usable base
Date: Wed, 30 Dec 2015 12:09:26 -0800 [thread overview]
Message-ID: <xmqqsi2jem15.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CALCETrUgsawpwkkjO_BpPHyOaH7NsJNU-4mF97a6NAxCMB5aUA@mail.gmail.com> (Andy Lutomirski's message of "Wed, 30 Dec 2015 02:40:12 -0800")
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...
next prev parent reply other threads:[~2015-12-30 20:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-30 10:40 Feature request: git bisect merge to usable base Andy Lutomirski
2015-12-30 18:54 ` Christian Couder
2015-12-30 20:09 ` Junio C Hamano [this message]
2016-01-04 18:15 ` Andy Lutomirski
2016-01-04 20:31 ` Junio C Hamano
2016-01-04 22:20 ` Andy Lutomirski
2016-01-04 22:38 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqsi2jem15.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=luto@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.