Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git
Hello *, Now that GHC 7.8.[12] is out of the door, the Git reorganization can be tackled further... After a short conversion with Austin and Edward it appears that the sensible course of action with respect towards moving to a proper Git submodule set-up is to fold-in the 5 Git repos listed below (which btw are all GHC wired-in packages) directly into ghc.git (the same way testsuite.git was a few months ago): - base - ghc-prim - integer-gmp - integer-simple - template-haskell IMO, the benefit/cost ratio of simplifying the workflow outweighs the benefit/cost ratio of turning those into proper Git submodules. This incremental step towards a fully git-bisect-able ghc.git does already allow bisecting to work on a larger time-range than it does now, as those wired-in packages are the most likely to break compilation if out-of-sync with ghc.git. If no objections are raised, I'm planning to implement this change next weekend (April 19th/20th). Any comments/questions/...? Cheers, hvr PS: After this step, the next remaining step would be to turn the remaining not-yet-submodule Git repos into proper submodule Repos (like haddock.git) and figure out how to get the sync-all convenience-tooling a bit more submodule friendly...
OK with me! Sounds simpler. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Herbert Valerio Riedel | Sent: 13 April 2014 08:59 | To: ghc-devs | Cc: Austin Seipp | Subject: Folding in base, integer-{gmp, single}, ghc-prim, and haskell- | template into ghc.git | | Hello *, | | Now that GHC 7.8.[12] is out of the door, the Git reorganization can be | tackled further... | | After a short conversion with Austin and Edward it appears that the | sensible course of action with respect towards moving to a proper Git | submodule set-up is to fold-in the 5 Git repos listed below (which btw | are all GHC wired-in packages) directly into ghc.git (the same way | testsuite.git was a few months ago): | | - base | - ghc-prim | - integer-gmp | - integer-simple | - template-haskell | | IMO, the benefit/cost ratio of simplifying the workflow outweighs the | benefit/cost ratio of turning those into proper Git submodules. | | This incremental step towards a fully git-bisect-able ghc.git does | already allow bisecting to work on a larger time-range than it does | now, as those wired-in packages are the most likely to break | compilation if out-of-sync with ghc.git. | | If no objections are raised, I'm planning to implement this change next | weekend (April 19th/20th). | | Any comments/questions/...? | | Cheers, | hvr | | | | PS: After this step, the next remaining step would be to turn the | remaining not-yet-submodule Git repos into proper submodule Repos | (like haddock.git) and figure out how to get the sync-all | convenience-tooling a bit more submodule friendly... | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs
Sounds good to me too.
On Mon, Apr 14, 2014 at 10:22 AM, Simon Peyton Jones
OK with me! Sounds simpler.
Simon
| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Herbert Valerio Riedel | Sent: 13 April 2014 08:59 | To: ghc-devs | Cc: Austin Seipp | Subject: Folding in base, integer-{gmp, single}, ghc-prim, and haskell- | template into ghc.git | | Hello *, | | Now that GHC 7.8.[12] is out of the door, the Git reorganization can be | tackled further... | | After a short conversion with Austin and Edward it appears that the | sensible course of action with respect towards moving to a proper Git | submodule set-up is to fold-in the 5 Git repos listed below (which btw | are all GHC wired-in packages) directly into ghc.git (the same way | testsuite.git was a few months ago): | | - base | - ghc-prim | - integer-gmp | - integer-simple | - template-haskell | | IMO, the benefit/cost ratio of simplifying the workflow outweighs the | benefit/cost ratio of turning those into proper Git submodules. | | This incremental step towards a fully git-bisect-able ghc.git does | already allow bisecting to work on a larger time-range than it does | now, as those wired-in packages are the most likely to break | compilation if out-of-sync with ghc.git. | | If no objections are raised, I'm planning to implement this change next | weekend (April 19th/20th). | | Any comments/questions/...? | | Cheers, | hvr | | | | PS: After this step, the next remaining step would be to turn the | remaining not-yet-submodule Git repos into proper submodule Repos | (like haddock.git) and figure out how to get the sync-all | convenience-tooling a bit more submodule friendly... | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Hi Herbert,
After a short conversion with Austin and Edward it appears that the sensible course of action with respect towards moving to a proper Git submodule set-up is to fold-in the 5 Git repos listed below (which btw are all GHC wired-in packages) directly into ghc.git (the same way testsuite.git was a few months ago):
This is just a confirmation. I have no opinion on this. Recalling the discussion in the last summer, I understood GHC project will start using git subtree, not git submodule. But it seems to me this is my misunderstanding. What was the conclusion of that discussion? And would you tell me why submodule was chosen? --Kazu
On 2014-04-15 at 05:38:54 +0200, Kazu Yamamoto (山本和彦) wrote:
Hi Herbert,
After a short conversion with Austin and Edward it appears that the sensible course of action with respect towards moving to a proper Git submodule set-up is to fold-in the 5 Git repos listed below (which btw are all GHC wired-in packages) directly into ghc.git (the same way testsuite.git was a few months ago):
This is just a confirmation. I have no opinion on this.
Recalling the discussion in the last summer, I understood GHC project will start using git subtree, not git submodule. But it seems to me this is my misunderstanding.
What was the conclusion of that discussion? And would you tell me why submodule was chosen?
I believe you refer to http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/1179 and the spin-off thread http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/1237 However, I couldn't find any conclusion while skimming through the threads stating that using 'git subtree' would have been the conclusion. Otoh, I can offer part of the motivation for using `git submodules` from my current point of view from the top of my head: - We already use Git submodules for half the sub-repos, using a mix of submodules and subtrees might become too confusing. - The remaining (after the wired-in packages are folded in) non-yet Git-submoduled repos at git.haskell.org are candidates for being moved to http://github.com/haskell/ (most are not specific to GHC (in theory at least) and are to become managed more actively by the core library committee, read "outsourced"), so they'd essentially become 3rd party tracked upstream repos, which is exactly the use-case that Git submodules are suited for. - Git subtrees embed the sub-repos' content into the super-repo, therefore once you don't need the subrepo anymore, you still have to carry around its content forever in the superproject. Git submodules only require to store the sub-repos commit-ids in the the super-repo (Git Submodules are basically what GHC fingerprints would provide if the GHC fingerprint would be checked into ghc.git and kept up-to-date with each ghc.git commit) - Git subtree is actually a Git contrib-script and may not be available in all Git installations. Submodules, otoh, have been an integral part of Git since version 1.5.3 Cheers, hvr
Hi Herbert, Thank you for your kind explanation! --Kazu
Otoh, I can offer part of the motivation for using `git submodules` from my current point of view from the top of my head:
- We already use Git submodules for half the sub-repos, using a mix of submodules and subtrees might become too confusing.
- The remaining (after the wired-in packages are folded in) non-yet Git-submoduled repos at git.haskell.org are candidates for being moved to http://github.com/haskell/ (most are not specific to GHC (in theory at least) and are to become managed more actively by the core library committee, read "outsourced"), so they'd essentially become 3rd party tracked upstream repos, which is exactly the use-case that Git submodules are suited for.
- Git subtrees embed the sub-repos' content into the super-repo, therefore once you don't need the subrepo anymore, you still have to carry around its content forever in the superproject. Git submodules only require to store the sub-repos commit-ids in the the super-repo
(Git Submodules are basically what GHC fingerprints would provide if the GHC fingerprint would be checked into ghc.git and kept up-to-date with each ghc.git commit)
- Git subtree is actually a Git contrib-script and may not be available in all Git installations. Submodules, otoh, have been an integral part of Git since version 1.5.3
Cheers, hvr
On 2014-04-13 at 09:58:50 +0200, Herbert Valerio Riedel wrote: [...]
- base - ghc-prim - integer-gmp - integer-simple - template-haskell
[...]
If no objections are raised, I'm planning to implement this change next weekend (April 19th/20th).
As there were no objections, I went on and implemented the change, so as of http://git.haskell.org/ghc.git/commit/41f5b7e3e0648302b9c5dc485917a391d21d15... the repositories mentioned above are now part of ghc.git, and the same procedure applies as when we folded-in testsuite some time ago. Moreover, the 'master' branches of the five repositories have been made read-only, as GHC HEAD development is to continue inside ghc.git. See also http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/3453 as well as http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/3482 for the previous testsuite.git fold-in and related issues Cheers, hvr
| As there were no objections, I went on and implemented the change, so | as of | | | http://git.haskell.org/ghc.git/commit/41f5b7e3e0648302b9c5dc485917a391d | 21d15a1 | | the repositories mentioned above are now part of ghc.git, and the same | procedure applies as when we folded-in testsuite some time ago. Great! But what, specifically, is "the same procedure"? That is, if I have an existing tree, what steps do I take to upgrade? Never underestimate how stupid I am with git. Thanks Simon
I would love a reply to this query. Currently I don't dare do 'git pull' into my active working trees. Specifically: what steps, if any, beyond 'git pull --rebase' do I need to do, to update my working trees. Thanks Simon | -----Original Message----- | From: Simon Peyton Jones | Sent: 21 April 2014 09:34 | To: 'Herbert Valerio Riedel'; ghc-devs | Subject: RE: HEADS-UP: Folding in base, integer-{gmp, single}, ghc- | prim, and haskell-template into ghc.git | | | | As there were no objections, I went on and implemented the change, so | | as of | | | | | | | http://git.haskell.org/ghc.git/commit/41f5b7e3e0648302b9c5dc485917a391 | | d | | 21d15a1 | | | | the repositories mentioned above are now part of ghc.git, and the | same | | procedure applies as when we folded-in testsuite some time ago. | | Great! But what, specifically, is "the same procedure"? That is, if I | have an existing tree, what steps do I take to upgrade? | | Never underestimate how stupid I am with git. | | Thanks | | Simon
participants (5)
-
Herbert Valerio Riedel -
Herbert Valerio Riedel -
Johan Tibell -
Kazu Yamamoto -
Simon Peyton Jones