Simon Marlow: > On 06/05/11 02:05, Manuel M T Chakravarty 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. > > I'm not sure Linus's concerns about merging apply to us. He's worried about > people merging the current state of his tree into other branches, because > intermediate states of his tree between releases are not necessarily sane - > there could be experimental code that gets completely removed before a > release. In contrast, the GHC master branch is intended to be relatively > sane at all times, we don't have big experimental changes that get backed out > again. So I don't think it's such a problem to sync branches with master > from time to time - indeed it makes managing branches much easier, because > you can merge incrementally.
Maybe I misunderstand, but I don't think that this is the only issue. There are three points to consider: (1) The GHC master always needs to validate. I don't think that means it doesn't contain random code. I certainly push incomplete work as long as it still leaves the compiler in a working state. I have always had the strong impression other people do the same. (2) Merges lead to merge commits. This creates unnecessary noise. Let's say we have ten people on ten branches. Each person merges from master once a day (and also produces at least one commit a day, so can't fast forward). When they finally merge the ten branches into the master, you get 10 useless merge commits per day of parallel development into the master. (3) AFAIK, if possible, you should rebase (not merge) your local development into the master to get a linear history. Overall, this suggests to me to work on a branch, where you merge from master only if it has changes that do directly affect the development that you are doing on the branch. When you are done (or reach a suitable intermediate state), you rebase onto the master. In order to be able to rebase from a dev branch into the master, we should probably consider some of the branches to be semi-private. Alternatively, people could use fork repositories on GitHub for their day-to-day work with private branches and rebase those to the d.h.o repo master and branches. Manuel _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
