[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: k-ohara5a5a
Subject: Re: Issue 2100: Explanation of branches for CG (issue 5539062)
Date: Sun, 15 Jan 2012 19:47:10 +0000


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
 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]