Hi Manuel, What is then the right way to do things? It is not clear to me from Linus's email. Consider the ghc-generics branch scenario: - A couple of repos are branched (compiler, ghc-prim, and others), but not all. These other repos are just using the "master" branch; - Two people work on it separately.
We have to merge from master relatively often because changes in the non-branched repos might depend on changes to the branched repos. Also, to keep the two developers in sync, we have to push to the branch rather often. We do end up pushing one thing and later pushing something that undoes the first thing, but is this a problem? Should we be using rebase? How? I'm sorry but I'm totally new to git. Cheers, Pedro On Fri, May 6, 2011 at 03:05, Manuel M T Chakravarty <c...@cse.unsw.edu.au>wrote: > 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
