Hi, On Sat, Jun 8, 2013 at 6:30 AM, Jeff Cody <jc...@redhat.com> wrote: > On Fri, Jun 07, 2013 at 11:51:36AM -0500, Anthony Liguori wrote: >> Laszlo Ersek <ler...@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 >
