Proposal: better library management ideas (was: how to checkout proper submodules)

Geoffrey Mainland mainland at
Wed Jun 12 14:28:50 CEST 2013

On 06/12/2013 12:37 PM, Ian Lynagh wrote:
> On Wed, Jun 12, 2013 at 12:54:38AM +0200, Daniel Trstenjak wrote:
>>> I guess [the merge commits] may not cause any actual problems,
>>> but it's certainly nicer
>>> not having them (which is what using submodules gives us).
> Just to clarify, my problem isn't so much that there are merge commits
> (although it would still be nicer if there weren't), but that it is hard
> to see whether we are in the same state as upstream, or to see what the
> differences between us and upstream are.
>> I don't quite understand how you should get rid of these merge commits
>> by using submodules,
> With submodules we can do
>     cd libraries/Cabal
>     git reset --hard <an upstream commit id>
>     cd ..
>     git commit -a
> and we will jump to that commit, without needing to merge it with the
> commit that we were at before.
>> You can get rid of these merge commit by using the '--rebase' option
of git-pull.
> We can't rebase, as these patches are in everyone else's GHC tree.

Only if you have pushed the "ghc" tree. If it is only local, then
rebasing is just fine. And, I would argue, desirable.

For the record, I am in favor of moving everything to submodules.


More information about the ghc-devs mailing list