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