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/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel