On 2012/01/15 19:47:10, Keith wrote:
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.
But we should not have all developers have to suffer from one developer's mistake on staging, when there is an easy way around it.
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
This would work, as long as the developer is completely aware of which commits are his and which are not. As long as the developer has abided by the "one commit per patch" rule, it's easy.
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.
Yes, but I wouldn't leave it in that state. The full set of commands is git rebase origin/staging dev/cg~0 git push origin HEAD:staging git checkout dev/cg At this point, you have pushed dev/cg to staging without polluting dev/cg with staging. And you can continue to rebase dev/cg with master as needed/desired. You never have to worry about accidentally putting some reverted commit back into staging. It's completely foolproof. The examples for the guide are intended to be copy and pastable, not necessarily to teach how to use git in general. Working commands that do what we want should be preferred to commands that require a developer to follow through some steps and make it right. The way I've actually recovered commits from broken staging in the past is with cherry-picks. But those weren't my commits. Even if they were mine, probably a new branch and cherry-picking off the broken staging is easier/cleaner than rebase -i. But the incomprehensible set of commands works perfectly on a detached head, and leaves the rebased tree in garbage collection where it will eventually be automatically eliminated, which is the appropriate place. I think it is the right set of commands. Thanks, Carl
I think (2) is the best example for the guide.
http://codereview.appspot.com/5539062/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
