what should patchy do for staging?

[Graham Percival]

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://github.com/gperciva/lilypond-extra.git

and then edit the
  patches/compile_lilypond_test.py

I think you are interested in the
    def merge_staging(self):
and
    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