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

[Carl . D . Sorensen]

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

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.  At any time I can do git rebase master
and I'll get the set of commits necessary to develop dev/cg from master.

The only time this fails is if two people have been working on the same
lines of the same file, in which case there will be a merge conflict,
and it will need to be resolved manually.  But there is nothing that can
be done about this.  We have to resolve the merge conflict when we do
the rebase -- but it's not an artifact of git, it's a real issue.


> I still wish that there was some way of using staging for this purpose
-- then
> the developer would always know that dev/cg is his (unspoiled) work,
> origin/staging is where he wants to put it, and staging is a temporary
storage
> location.

Why do we need a temporary storage location? The only difference between
staging and origin/staging is a timing issue -- staging may be behind
origin/staging because changes have happened when I did git fetch.  But
I can't push to origin/staging until I rebase to origin/staging.

It works just the way you want it to out of the box.

When I went and gathered James's commits to push to staging, I didn't
make *any* changes to his work.  I just created a branch, applied his
patch, rebased to origin/staging, and pushed.  And it went seamlessly.




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