[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

what should patchy do for staging?

From: Graham Percival
Subject: what should patchy do for staging?
Date: Wed, 9 Nov 2011 12:07:05 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

On Wed, Nov 09, 2011 at 09:58:56AM +0100, David Kastrup wrote:
> [Diversion: by the way, Phil and Graham?  I have come to the conclusion
>   that it is better if Patchy does not attempt any rebases or merges on
>   its own.  Can you change that accordingly?  It should quite simplify
>   Patchy and make its behavior more predictable: it would just try to
>   push its tested version of dev/staging to master, and if that fails,
>   it fails.

I am in the middle of reinstalling OSes, setting up development
environments, and making the 2.15.17 release.  And I do not
understand, nor do I *care* to understand, the difference between
rebase and merge.

Run this command:
  git clone git://

and then edit the

I think you are interested in the
    def merge_staging(self):
    def merge_push(self)
and maybe the
    def staging()

functions.  Send patch, or push directly to github if you have an
account there.  I am totally not picking about patches to
lilypond-extra at all.  No review (unless you want one), no
countdown, no fuss.

If anybody else is reading this, and knows (or cares) about git,
and knows (or cares) about setting up an automatic tool to make
our lives easier, you could follow the same instructions.

Have fun.

> Maybe we should rename the staging branch into just
>   "staging" as the "dev/" is needlessly obscure. ]

sure, that's fine with me.

- Graham

reply via email to

[Prev in Thread] Current Thread [Next in Thread]