From: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
To: Jeff Cody <jcody@redhat.com>
Cc: kwolf@redhat.com, Anthony Liguori <aliguori@us.ibm.com>,
qemu-devel@nongnu.org, blauwirbel@gmail.com,
alex.williamson@redhat.com, stefanha@redhat.com,
Laszlo Ersek <lersek@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] script: git script to compile every commit in a range of commits
Date: Mon, 10 Jun 2013 19:41:32 +1000 [thread overview]
Message-ID: <CAEgOgz6HX21xAP-yPzy_vT=fcUubs2=d8rc=y2jZ2AqO6d0-kA@mail.gmail.com> (raw)
In-Reply-To: <20130607203054.GC23710@localhost.localdomain>
Hi,
On Sat, Jun 8, 2013 at 6:30 AM, Jeff Cody <jcody@redhat.com> wrote:
> On Fri, Jun 07, 2013 at 11:51:36AM -0500, Anthony Liguori wrote:
>> Laszlo Ersek <lersek@redhat.com> writes:
>>
>> > On 06/07/13 16:44, Jeff Cody wrote:
>> >
>> >> Thanks. I can either do the above changes for a v2, or as follow on
>> >> patches.
>> >
>> > Whichever is easier for you, certainly! I'm fine with the script
>> > going-in as is.
>>
>> A suggestion I'll make is to split the script into two parts.
>
> Hi Anthony,
>
> I'm sorry, but I'm a bit confused by your suggestion. I think I know
> what you are asking (see below), but I'm not positive.
>
>> git-bisect run is a terribly useful command and I use a bisect script
>> that looks like this:
>>
>> #!/bin/sh
>>
>> set -e
>>
>> pushd ~/build/qemu
>> make -j1 || exit 1
>> popd
>>
>> # Add right seed here
>> if test "$1"; then
>> "$@"
>> fi
>>
>> I'm sure we all have bisect scripts like this.
>>
>> What you're proposing is very similar to bisect but instead of doing a
>> binary search, it does a linear search starting from the oldest commit.
>> Basically:
>
> I agree that git bisect is useful, but solves a slightly different
> problem than what I am looking to solve.
>
> For instance, in my working branches I have a whole stack of commits
> that I will rebase and squash into a set of sane patches before
> submitting. To make sure I don't do something silly in that process,
> and create a patch X that does not build without patch X+1, I want to
> explicitly compile each patch, without skipping over any patches.
>
>
>> #!/bin/sh
>>
>> refspec="$1"
>> shift
>>
>> git rev-list $refspec | while read commit; do
>> git checkout $commit
>> "$@" || exit $?
>> done
>>
>> And indeed, I have a local script called git-foreach to do exactly
>> this. I suspect a nicer version would make a very good addition to the
>> git project.
>>
>> So to bisect for a make check failure, I do:
>>
>> git bisect run bisect.sh make check
>>
>> Or to bisect for a qemu-test failure:
>>
>> git bisect run bisect.sh qemu-test-regress.sh
>>
>> With git-foreach, you can do:
>>
>> git-foreach bisect.sh
>>
>> To do a simple build test. Or you can do:
>>
>> git-foreach git show checkpatch-head.sh
>>
>> etc.
>
> Ah! So if I understand correctly, what you are asking is to split
> the script up into two different scripts:
>
> 1.) A 'foreach' framework script to run an arbitrary command over a
> range of commits, against each commit (i.e. in the place where I run
> 'make clean, git checkout, configure, and make [lines 188-191], simply
> do the git checkout and execute a passed script / command).
>
> 2.) A second script to perform the complication check, intended to be
> called by script 1). We could then add additional scripts to be
> called by the 'foreach' framework patch as desired.
>
> Heck, if we wanted to, we could then even create a menu-drive
> meta-script to interactively run any number of tests (checkpatch,
> compilation, etc..) using that framework.
>
Make sense to me. I have a little script that does this stuff for me,
but my for-each mechanism runs using git am rather than commit ranges
and git checkout. Verifies that the series as-about-to-be-sent applies
cleanly to the master without build breakage or checkpatch fail.
If you make this two stage split developers can choose between either
a commit or am based foreach iterator and the second script as your
call it is common to both.
Regards,
Peter
>>
>> Regards,
>>
>> Anthony Liguori
>>
>
> Thanks,
>
> Jeff
>
next prev parent reply other threads:[~2013-06-10 9:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-31 16:39 [Qemu-devel] [PATCH] script: git script to compile every commit in a range of commits Jeff Cody
2013-06-06 8:58 ` Laszlo Ersek
2013-06-07 14:44 ` Jeff Cody
2013-06-07 15:40 ` Laszlo Ersek
2013-06-07 16:51 ` Anthony Liguori
2013-06-07 20:30 ` Jeff Cody
2013-06-10 9:41 ` Peter Crosthwaite [this message]
2013-06-07 16:36 ` Peter Crosthwaite
2013-06-07 19:13 ` Jeff Cody
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='CAEgOgz6HX21xAP-yPzy_vT=fcUubs2=d8rc=y2jZ2AqO6d0-kA@mail.gmail.com' \
--to=peter.crosthwaite@xilinx.com \
--cc=alex.williamson@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=blauwirbel@gmail.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=lersek@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).