All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.