Thomas Morley <thomasmorle...@gmail.com> writes: > 2013/8/27 Thomas Morley <thomasmorle...@gmail.com>: >> 2013/8/27 Graham Percival <gra...@percival-music.ca>: >>> On Tue, Aug 27, 2013 at 01:36:24PM +0200, Thomas Morley wrote: >>>> To be sure: am I right that it will succeed only _after_ Graham >>>> granted membership? >>> >>> Approved now. >>> >>> Cheers, >>> - Graham >> >> Thanks! >> Afaics, all works and I've push-access. >> >> Next step: I'll reread CG _how_ to push. >> :) >> >> Best, >> Harm > > Actually trying to push I followed CG and did > > git checkout staging > git pull -r > git merge dev/handle-grace
Uh what? So much for stating that CG is our best reference. > Now an editor pops up with: > > Merge branch 'dev/handle-grace' into staging > > # Please enter a commit message to explain why this merge is necessary, > # especially if it merges an updated upstream into a topic branch. > # > # Lines starting with '#' will be ignored, and an empty message aborts > # the commit. > > > The patch already has a commit-message. > Should I write here something additional? git merge --abort You don't want a merge commit for a simple patch (assuming that every commit in your branch results in a working version of LilyPond). Then git fetch git rebase origin dev/handle-grace and git push origin HEAD:staging Note that this will refuse to push in case staging is ahead of master. Usually you don't want to push in that situation anyhow since things will get really complicated in case the material in staging will _not_ test out fine and get pushed to master. So you just wait a few hours and then start over with "git fetch". -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
