My only concern with this is that we consider the workflow and tooling issues that I outlined in http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2718 The main points are making sure the workflow for submodules doesn't have too much friction, that it's integrated nicely into sync-all, and that we avoid the worst pitfall of submodules: losing local changes to a submodule on a git submodule update. I think this means that sync-all pull should do either 'git submodule update --merge' or 'git submodule update --rebase' depending on whether you used sync-all pull --rebase or not. But caveats apply, I've only skimmed the docs and not tried this out for real :-) OTOH, it's not hard to do manual cherry-picks with git. 'git show <hash> | patch -p1' is something I often do, and 'git commit -C <commit>' reuses the metadata from another commit. So it's probably not essential that we do this now. Cheers, Simon On 04/12/2013 21:24, 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.