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

[graham]

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.

Is there any way we can avoid this?  The only way I've thought of so far
is to produce an *additional* staging-dev/cg branch from dev/cg, rebase
staging-dev/cg on origin/staging, then merge (or rebase) staging-dev/cg
on staging and push that.

I know it really complicates stuff, but given our history of bad commits
in staging, it would be sheer folly to assume that it will never happen
again.

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.

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