LGTM On 2012/01/15 08:05:35, Graham Percival wrote:
With this recipe, the broken-staging will be in the developer's personal dev/cg branch.
Is there any way we can avoid this?
1) We could accept it as a consequence of re-writing the public history on origin/staging. When the developer does his next rebase -i he should recognize that some commits are not his, and remove them from the rebase --or test them and fix the problem that forced the rewind of staging. 2) We could introduce both 'merge' and 'rebase' in the guide: git checkout staging git reset --hard origin/staging # reset local staging to the repository git merge dev/cg # bring your new commits into local staging git rebase -i origin/staging # rewrite local history to put the new commits last gitk # check that the commits look as you intended git push origin/staging On 2012/01/15 13:37:13, Carl wrote:
git rebase origin/staging dev/cg~0 git push origin HEAD:staging
3) The example above is certainly shorter. I find it difficult to understand. It implicitly checks out the last commit in dev/cg (leaving git not on any branch). I would not have guessed that this would be supported, based on `man git rebase`. Then the command rebases that non-on-any-branch history to origin/staging and pushes that history to the repository. It leaves git in the state of being not on any branch. I think (2) is the best example for the guide. http://codereview.appspot.com/5539062/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
