On 06/06/2013 02:42 AM, Kazu Yamamoto (山本和彦) wrote:
There are a lot of things to recommend moving to github. I do hate (non-empty) merge commits, though, so I'm not a fan of github's pull request mechanism.
Please read "A successful Git branching model" to know why fast-forward is not used recently.
Git flow: http://nvie.com/posts/a-successful-git-branching-model/
Another relating article is here:
Github flow: http://scottchacon.com/2011/08/31/github-flow.html
--Kazu
I have read both of these before. GHC does not use the git flow model advocated in those two articles. The choice to rebase private feature branches is orthogonal to the choice to use --no-ff when merging feature branches. I am of the opinion that major feature branches should be rebased *and* that they should then be merged with --no-ff. However, GHC's history is a mess. A small fix does not require a feature branch, and yet GHC's history has many, many small changes that have all been merged instead of rebased. The postings you cite don't really take a stand on rebasing private feature branches. Here are a few that do. Git merge vs. rebase http://mislav.uniqpath.com/2013/02/merge-vs-rebase/ A Rebase Workflow for Git http://randyfay.com/content/rebase-workflow-git I realize that this is a religious issue. However, perhaps it is less controversial for me to claim that the GHC history is a mess. Can we easily do something about that by making a minimally intrusive change to our workflow? Geoff