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