Daniel Pittman wrote:
Andreas Ericsson <ae@xxxxxx> 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.
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@xxxxxx
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
