Re: Issue 2100: Explanation of branches for CG (issue 5539062)

[k-ohara5a5a]

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/