Simon Marlow: > Some of us are using rebase to avoid merge commits where possible, but it is > quite easy to get into a mess so I hesitate to suggest rebase as our > recommended workflow. Ordinary merging works fine modulo the noisy merge > commits, so I'm happy for people to just do 'git pull' unless they're > comfortable with rebase. Some projects require their developers to be git > experts; I don't think that's practical for us. Maybe that will change over > time, I don't know. > > One reason that rebase isn't straightforward for us is the two-tree validate > workflow. We've discussed this quite a bit on IRC and I don't think there's > a good solution. Basically what happens is this: > > - you develop in your working tree and commit patches there. At > this point it's completely safe to rebase - the patches are only > in one place. > > - you pull the patches into the validate tree (you just rebased in > working, so no conflicts or merges required here) > > - run validate (takes ~30 mins) > > - try to push - oops, someone else already pushed something > > - now we have a choice: merge or rebase. > > - merge: we get a merge commit, but later pulling into the working > tree works fine. > > - rebase: no merge commit, but we have to remember to rebase the > working tree again, otherwise the next pull will be a conflict. > > I've been doing the rebase scheme and it generally works ok: git notices when > it is rebasing a patch that already exists, and discards it. But, it's > complicated enough that I'm wary of recommending this as our standard > workflow. (also, needing rebase feels wrong somehow, but that's more of a > philosophical point).
I agree with this workflow. I am not quite sure why you think it is too complicated. The rule is simple: rebase is a one-way street (it changes patches and doesn't just move them), so you cannot just merge back into the re-based branch. SimonPJ asked for a recipe of how to proceed with git. I think you just provided that. (Re the philosophical point, I agree, it is disturbing to functional programmers as rebase mutates patches. Darcs idea of commuting patches appears more elegant, but git has the more mature implementation and all the infrastructure.) Manuel _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
