Repository Reorganization Question

Geoffrey Mainland mainland at apeiron.net
Thu Dec 5 18:19:33 UTC 2013


I'm all for converting to submodules. Since we will have submodules
anyway, we could also convert testsuite et al to submodules and see how
painful that is before deciding to fold them in to the main repo. I'm
not clear on the pros/cons of having, e.g., testsuite, as a submodule vs
folded in. The submodule approach will certainly maintain history!

Geoff

On 12/04/2013 04:24 PM, Austin Seipp wrote:
> Hi all,
>
> While discussing something with Herbert this week in preparation of
> making a new stable branch, he brought a good point to my attention,
> which is that if we go ahead and reorganize the repository situation
> post 7.8, merging things to the stable branch from HEAD will become a
> bit harder.
>
> Notably, we had planned to fold testsuite (and perhaps some other
> repositories) into the GHC tree. Once we do this, the two branches
> will have diverged quite a bit, so merging from HEAD to STABLE will
> become harder* (because HEAD would have rolled in testsuite changes
> for example, but the STABLE branch would not have this history.)
>
> Thinking about it, the best time to do such a move is, basically, when
> there is no active stable branch. Unfortunately this time is right
> now, but I'm not sure how everyone feels about this.
>
> So, the question is: should we go ahead and pull the trigger on some
> of these perhaps? Herbert collected some numbers on the git
> repositories and outlined all the basic details here:
>
> https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization
>
> The only thing I'd honestly propose right now is folding 'testsuite'
> into the main repository, but of course we should see what people
> think - perhaps we should keep base/etc off the table for now, since
> they seem more controversial.
>
> * I'll point out they will only become *slightly* harder in most
> cases, because I can always instead apply unified diffs, rather than
> cherry pick or something. But it does lose the original metadata from
> commits too. But I won't cry if people vote against this.
>



More information about the ghc-devs mailing list