Peekay Ex <pkx1...@gmail.com> writes: > Yes and I suppose that is why I cannot push these patches to dev\staging > > --snip-- > > jlowe@jlowe-lilybuntu2:~/lilypond-git$ git push origin > HEAD:refs/heads/dev/staging > To ssh://pkx1...@git.sv.gnu.org/srv/git/lilypond.git > ! [rejected] HEAD -> dev/staging (non-fast-forward) > error: failed to push some refs to > 'ssh://pkx1...@git.sv.gnu.org/srv/git/lilypond.git' > To prevent you from losing history, non-fast-forward updates were rejected > Merge the remote changes before pushing again. See the 'Note about > fast-forwards' section of 'git push --help' for details. > --snip-- > > Is there something I can do on my side to push these to dev\staging?
For single patches, this is reasonably simple. First do git rebase origin/dev/staging and then push. This flattens out merge commits however. If you want to preserve merges as merges (because the state in between is untested or known to break tests), you need to do git rebase -p origin/dev/staging If you merge commits in between, it will likely bomb out complaining that it does not know which part of the merge is supposed to be the mainline (that used for bisection). You usually can continue by saying git cherry-pick -m 1 commit-id-that-git-complained-about git rebase --continue But for most patches, the simple rebase should be totally sufficient. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel