git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Pittman <daniel@rimspace.net>
To: git@vger.kernel.org
Subject: Re: Test that every revision builds before pushing changes?
Date: Fri, 27 Mar 2009 12:30:07 +1100	[thread overview]
Message-ID: <8763hviwgw.fsf@rimspace.net> (raw)
In-Reply-To: 49CB4ED8.4060205@op5.se

Andreas Ericsson <ae@op5.se> writes:
> Daniel Pittman wrote:
>> 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.

[...]

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

We have that also; I am primarily motivated by avoiding trivial breakage
in the CI server, as well as bisection.

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

[...]

> 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

Thank you, that points me in the right direction, and I can obviously
season the rest of it to taste — reverse that revision list, for
example.

Thank you also to Wincent Colaiuta, who provided a similar script albiet
with significantly more detail.

[...]

> It doesn't handle merges very nicely, btw, but I guess this should be
> run prior to merging anyways.

Once I have the framework I can quietly work my way through fixing nasty
issues one way or another.  Thanks.

Regards,
        Daniel

  reply	other threads:[~2009-03-27  1:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-26  6:29 Test that every revision builds before pushing changes? Daniel Pittman
2009-03-26  8:16 ` Andreas Ericsson
2009-03-26  9:10   ` Daniel Pittman
2009-03-26  9:46     ` Andreas Ericsson
2009-03-27  1:30       ` Daniel Pittman [this message]
2009-03-26  9:49     ` Jeff King
2009-03-26  9:59       ` Wincent Colaiuta

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=8763hviwgw.fsf@rimspace.net \
    --to=daniel@rimspace.net \
    --cc=git@vger.kernel.org \
    /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).