[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: Carl . D . Sorensen
Subject: Re: Issue 2100: Explanation of branches for CG (issue 5539062)
Date: Sun, 15 Jan 2012 23:12:49 +0000

On 2012/01/15 19:47:10, Keith wrote:

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
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
  git merge dev/cg               # bring your new commits into local
  git rebase -i origin/staging # rewrite local history to put the new
  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
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.



I think (2) is the best example for the guide.

reply via email to

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