qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
>

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