Version control systems

[Thomas Schilling]

> 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/