Simon Peyton-Jones: > It's a long message and I don't understand it. > > Suppose we have > * A branch > * Shared between several people > * Long-lived (weeks not day) > how should we manage it? > > It *must* be possible to merge fixes from the master into the branch. Doing > so, and then validating, is essential because (as we have painfully learned) > it simply isn't possible to anticipate all interactions. Moreover, quite > often the master is changing (say) the type checker and so is the branch; > Linus seems to regard this as exceptional, but to me it seems the norm.
Linus does say that if there is a real dependence of your new code on changes in the master, you need to get those changes. He just discourages pulling changes in from the master out of habit. > If someone would like to write a duffers guide describing how to do that, I'm > happy to follow it. But the only way I understand is to merge master onto > the branch regularly, and finally merge the branch onto the master. I don't > see the disadvantage of this approach. Yet. In my limited understanding of git, you should use rebase to add your changes to the master, where possible. Otherwise, you end up with a muddled history and lots of spurious merge commits. (I have never used git on a large project, so I'm really just regurgitating the advice of others.) We can of course continue to use our old darcs-ish workflow with git and see what happens. In all likelihood, we'll find the same problems others found. I doubt Linus and other longterm git users adopted their more involved workflows without a reason. Manuel _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
