> If you have lots of local changes (e.g. the sorts of long-running branch > that gives darcs 1 problems), then you need to use merge. If you use > rebase then you might end up with lots of conflicts to manually resolve. > > Using merge gives you automatic merge commits, If you think these are > ugly (opinion is divided on that amongst git people; I guess for GHC > we'd want to make a global decision about that) then you can use rebase > when you have few local changes, and thus you are unlikely to get many > conflicts. > > Using merge you also get a more accurate reflection of the project > history, i.e. you can see that the two branches were being developed > independently.
That's not quite accurate: If you have conflicts, you have conflicts and have to resolve them manually. In case of a branch, however, you only have to resolve them once you do the merge, so when _you_ decide, not whenever some upstream change breaks things. Some projects encourage to have one development branch and periodically update the master branch and rebase the development branch on top of it. I think it's a matter of taste and we should probably advocate one usage. I think rebase should only be used for smaller changes. The automatic usefulness of the automatic merge message is varying. I think it makes sense if it contains public repos, like, e.g. "Merge 'master' from git://github.com/chak/ghc", but less useful for pulls from local repos like, e.g. "Merge 'master' from '/home/igloo/tmp/trash/ghc/fix-stupid-osx-bug/'". However, if we prefer merges we get those pretty git history graphs: http://www.flickr.com/photos/malcolmtredinnick/1516857444/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users