I did say earlier that git rebase was analogous to saving a series of
commits and applying them, but there is a difference in that `git rebase



http://codereview.appspot.com/5484043/diff/7001/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):

http://codereview.appspot.com/5484043/diff/7001/Documentation/contributor/source-code.itexi#newcode446
Documentation/contributor/source-code.itexi:446: git rebase dev/cg
This makes the history of commits linear, but in the wrong order. (It
puts any new commits from the repository /after/ the new commits from
dev/cg -- and any conflict resolution would change the commits from the
repository.)

Git changes the branch that is checked-out, and we want to change the
sequence of commits developers branch, so
 git checkout dev/cg
 git rebase staging
 git checkout staging
 gitk

http://codereview.appspot.com/5484043/

_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Reply via email to