Am 05.05.2014 10:49, schrieb James:
On 05/05/14 05:42, Urs Liska wrote:
Am 05.05.2014 03:50, schrieb Graham Percival:
On Fri, May 02, 2014 at 06:02:48PM +0000, lilyli...@googlemail.com
wrote:
Updated patch, now applied to master.
I hope you mean "now applied to staging". You should never push
anything directly to master.
Well, Patchy the autobot complained that the initial patch didn't
apply to master ...
But don't worry, I'm fully aware of the set-up and will of course move
the commit to the current HEAD of _staging_ when time comes to push.
Urs
Patchy compiles *against* master as that is always the benchmark (so to
speak).
If it doesn't compile against master then there is no point checking it
in to staging.
Then when patchy eventually comes to merge the two (staging and master)
and it fails then we still have a working master and only staging is
broken.
James
What I do is branching off from master and work on the patch.
When I'm ready to upload for review I pull any new commits from origin,
rebase my branch to master and do git cl upload origin/master - which is
what the CG suggests.
When the review is finished I pull again and (now) apply my patch on
staging and push there.
Previously I rebased my branch on master again and sent the patch to the
list because I thought that staging might have changed already when
someone handles my request.
So I think everything is clear.
But if you would prefer that one _always_ works against staging the CG
section 3.3.4 should be changed.
Urs
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
