how to checkout proper submodules
Geoffrey Mainland
mainland at apeiron.net
Thu Jun 6 09:35:20 CEST 2013
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
More information about the ghc-devs
mailing list