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

[Carl . D . Sorensen]

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/