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. So I think merging the master onto the branch must be done regularly not as a big bang at the end. 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. Simon | -----Original Message----- | From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On Behalf Of | Manuel M T Chakravarty | Sent: 06 May 2011 02:06 | To: GHC | Subject: Git, merging and rebasing | | There seems to be quite a bit of merging from master into branches going on in the | GHC repos at the moment. This isn't necessarily a good way of using Git as Linus | explains in this message: | | http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html | | The way I understand it is that Git avoids the performance problems of darcs when | branching and merging (by not trying to commute patches), but the price we have to | pay for that is the resulting fixed order of patches as well as merge patches | cluttering up the history. So, maintaining branches requires a bit more care. | | Manuel | | | _______________________________________________ | Cvs-ghc mailing list | Cvs-ghc@haskell.org | http://www.haskell.org/mailman/listinfo/cvs-ghc _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
