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