Re: Test that every revision builds before pushing changes?
Show 26 quoted lines
> Andreas Ericsson <ae@op5.se> writes:
>> Daniel Pittman wrote:
>>> I would like to ensure that my commits are fully bisectable before I
>>> commit them to an upstream repository, at least to the limits of an
>>> automatic tool for testing them.
>>>
>>> 'git bisect run' is similar: it can automatically locate the breaking in
>>> a test suite, for example, but that doesn't help me in the case of three
>>> commits, A (good), B (bad) and C (good, fixing B).
>>>
>>> I would much rather, in this case, use rebase to fix B so that it, too,
>>> builds before I push the changes and pollute a public repository with a
>>> broken changeset — and make bisect that much harder to use in future.
>> You can do that, but it requires manual work too. The trick is to make
>> the release branch immutable on the public repository and use topic
>> branches with per-developer namespaces. The per-developer namespace
>> thing is actually important, as it leaves the freedom to rewind and
>> recreate topics to the developers (which shared branches do not).
>>
>> The manual step comes at merge-time; Someone has to be responsible for
>> merging all the topics that are to be included in the release branch
>> and make sure it builds and passes all tests after each merge.
>
> Ah. You have not quite grasped what I was looking for: I was after a
> tool to help automate that step, rather than a workflow around it.
>
Oh right. Sorry, I'm stuck in continuous-integration land where people tend to want the server to take care of such things.
Show 16 quoted lines
> For example, the responsible person for that testing could use the
> hypothetical (until someone tells me where to find it):
>
> git test public..test make test
>
> Which would then effectively wrap:
>
> for each revision between public and private:
> git checkout revision
> make test
> # report if that fails, allow fixing the commit or whatever
> # then 'git test continue' to carry on...
>
> That turn the process from a manual one to an automated one: it runs
> that command for every revision until it fails, or until they all pass.
>
Something like this? --%<--%<-- #!/bin/sh
git stash
revspec="$1"
shift
for rev in $(git rev-list "$revspec"); do
git checkout $rev
"$@" || break
done
--%<--%<--
Run it as such: ./git-test.sh public..test make test
Adding support for "continue" in there shouldn't be hard, since you'd just replace the first rev with the first parent of the last tested revision, although if you want to fix up a commit in the middle, you'd have to manually rebase the other ones onto the newly created commit (again, not very hard but I'll leave both as an exercise to you).
It doesn't handle merges very nicely, btw, but I guess this should be run prior to merging anyways.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
Daniel Pittman
