Proposal: better library management ideas (was: how to checkout proper submodules)
Geoffrey Mainland
mainland at apeiron.net
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.
Geoff
More information about the ghc-devs
mailing list