On 09/05/2011, at 12:34, Manuel M T Chakravarty wrote: > Simon Marlow: >> >> - 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.
I'm rather lost now. Do we have to do this for the libs, too? Does sync-all support rebase? It doesn't seem to. Could this be added? Also, how do I find out if a branch has been rebased? And how do I rebase two branches (or two trees) in sync? As usual, I'm too stupid to understand the git docs. This all *is* quite complicated. Roman _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
