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

[dak]

On 2012/01/15 12:18:57, Carl wrote:
> On 2012/01/15 08:05:35, Graham Percival wrote:
> >

http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi
> > File Documentation/contributor/source-code.itexi (right):
> >
> >

http://codereview.appspot.com/5539062/diff/1/Documentation/contributor/source-code.itexi#newcode450
> > Documentation/contributor/source-code.itexi:450: git rebase
origin/staging
> > Problem: approximately once every 2 weeks, origin/staging is broken.
 As a
> > result, we delete the existing origin/staging branch, test a subset
of
> patches,
> > push them, etc etc.  You've seen the mess that happens.  With this
recipe, the
> > broken-staging will be in the developer's personal dev/cg branch.
> >

> I think you misunderstand what git rebase does.

I am afraid that this honor is entirely on your side.

> git rebase origin/staging does
> *not* bring origin/staging into dev/cg; it creates commits that are
necessary to
> get dev/cg from origin/staging.

If dev/cg is the current branch, git rebase origin/staging _does_
bring origin/staging into dev/cg, and on top of that puts all those
commits that have been in dev/cg but not in origin/staging.
Afterwards, dev/cg is a proper descendant of origin/staging, and the
commits that have been in origin/staging are an integral part of it
indistinguishable from original dev/cg commits in itself.

> If origin/staging is bad, and then deleted, and
> then built again as a new origin/staging, the developer can get the
appropriate
> set of commits by just reissuing git rebase origin/staging.

But those commits that have been excised from origin/staging are now
in the set origin/staging..dev/cg and will in consequence get
_reapplied_ on top of the fresh origin/staging.  There are two ways
out.  The hairy one:

git rebase the-old-origin-staging-commit-id --onto origin/staging dev/cg

This will take just the commits in dev/cg that are on top of the old
origin/staging and apply them on top of the new origin/staging.  This
requires you to keep track of what commits are your own, and which
commits have sneaked into your branch from an excised staging.

The less hairy one is not to rebase dev/cg on staging ever.  Instead,
rebase on origin (which never gets rewound):

git rebase origin dev/cg

And if staging is _beyond_ origin, you can now do

git rebase origin/staging dev/cg~0

before testing and pushing.  Note that dev/cg~0 does _not_ rebase
dev/cg, but does the rebase operation on a "detached HEAD".  dev/cg
proper remains rebased on origin/master.

> It works the way you want it to work.  dev/cg *always* holds the
> pristine copy of the developer's work.  git rebase origin/staging
> doesn't change dev/cg one bit.

If dev/cg is the currently checked out branch, it most certainly will.


http://codereview.appspot.com/5539062/