RE: [commit: ghc] master: Convert haddock into a proper submodule (re #8545) (34b0721)
Do us naïve users need to change our workflow with these submodule changes?
Thanks
Simon
| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of
| git@git.haskell.org
| Sent: 23 March 2014 09:50
| To: ghc-commits@haskell.org
| Subject: [commit: ghc] master: Convert haddock into a proper submodule
| (re #8545) (34b0721)
|
| Repository : ssh://git@git.haskell.org/ghc
|
| On branch : master
| Link :
| http://ghc.haskell.org/trac/ghc/changeset/34b072177b687c8fcc24f87293beae0
| 752e82d32/ghc
|
| >---------------------------------------------------------------
|
| commit 34b072177b687c8fcc24f87293beae0752e82d32
| Author: Herbert Valerio Riedel
On 2014-03-23 at 19:53:55 +0100, Simon Peyton Jones wrote:
Do us naïve users need to change our workflow with these submodule changes?
Probably yes... to some extent at least; that's why only haddock.git has been converted for now[1]: to find out empirically what's involved before continuing with the submodule-conversion. I've tried to describe one possible workflow (for if you need to publish a modification to haddock.git) at https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#Maki... I hope it makes a bit of sense :-) IMO, it's quite useful to familiarize oneself with the 'git submodule' family of commands, and especially 'git submodule' and 'git submodule summary', as those two introspection commands allow one to get a better picture in which state the currently cloned GHC working tree's submodules are. [1]: OTOH, haddock.git is not the first/only proper Git submodule we have so far; so, in some way this isn't much of a change...
OK. Some questions. · Where is a good place to get a conceptual understanding of submodules? Concerning https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules · Under "Updating an existing source tree clone" you say we have to do "git submodule update --init". What happens if we forget? Couldn't sync-all do that? (Indeed it now emits a message to that effect bash$ ./sync-all pull --rebase ... From http://git.haskell.org/packages/dph aeef7aa..2984641 master -> origin/master 962c999..556e09c ghc-7.8 -> origin/ghc-7.8 First, rewinding head to replay your work on top of it... Fast-forwarded master to 2984641ae0c4739b168ee1fb956fd54f741f30e7. == running git pull --rebase remote: Counting objects: 581, done. remote: Compressing objects: 100% (276/276), done. remote: Total 420 (delta 327), reused 189 (delta 142) Receiving objects: 100% (420/420), 74.21 KiB, done. Resolving deltas: 100% (327/327), completed with 108 local objects. From http://git.haskell.org/ghc df409de..15b1eb7 master -> origin/master abb86ad..a617888 ghc-7.8 -> origin/ghc-7.8 * [new branch] wip/T8545-ghc-7.8 -> origin/wip/T8545-ghc-7.8 * [new branch] wip/recurs-compat -> origin/wip/recurs-compat First, rewinding head to replay your work on top of it... Applying: Add missing kind-check for tcEqType on forall-types Applying: Don't export isTcReflCo_maybe (unused) Applying: Comments only Applying: For equalities with incompatible kinds, new IrredCan goes in the inert set, not work list Applying: Debug tracing only Applying: Flattener preserves synonyms, rewriteEvidence can drop buggy "optimisation" Applying: Implicit parameters should not be allowed in class and instance declarations Applying: Comments only == running git submodule update == Checking for old haddock repo == Checking for old binary repo · Under “Overriding pushurl”, same question. Couldn’t that long “git submodule foreach” command be done by sync-all? · Under “Making changes”, this looks hard to me. Is “base” a submodule? Does that mean we have to remember to do some incantations before we modify base? What if you forget and make the modifications first? Again, could some of this be automated, at least for the common workflow of pull/push? Thanks for working on this Simon · | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 23 March 2014 21:03 | To: Simon Peyton Jones | Cc: ghc-devs@haskell.org | Subject: Re: [commit: ghc] master: Convert haddock into a proper | submodule (re #8545) (34b0721) | | On 2014-03-23 at 19:53:55 +0100, Simon Peyton Jones wrote: | > Do us naïve users need to change our workflow with these submodule | > changes? | | Probably yes... to some extent at least; that's why only haddock.git has | been converted for now[1]: to find out empirically what's involved | before continuing with the submodule-conversion. | | I've tried to describe one possible workflow (for if you need to publish | a modification to haddock.git) at | | | https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#Maki... | MakingchangestoGHCsubmoduleshttps://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#Maki... | | I hope it makes a bit of sense :-) | | IMO, it's quite useful to familiarize oneself with the 'git submodule' | family of commands, and especially 'git submodule' and 'git submodule | summary', as those two introspection commands allow one to get a better | picture in which state the currently cloned GHC working tree's | submodules are. | | [1]: OTOH, haddock.git is not the first/only proper Git submodule we | have so far; so, in some way this isn't much of a change...
Hello Simon, On 2014-03-24 at 09:37:32 +0100, Simon Peyton Jones wrote:
OK. Some questions.
· Where is a good place to get a conceptual understanding of submodules?
There were three links at the top of the Wiki page; I assume you want something better than that?
Concerning https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules
· Under "Updating an existing source tree clone" you say we have to do "git submodule update --init". What happens if we forget? Couldn't sync-all do that? (Indeed it now emits a message to that effect
sync-all can do that of course; at this point, I'm just collecting all direct `git` commands one would have to enter if there wasn't a sync-all script -- once everything is in place, a new radically stripped down `sync-all` can be constructed for the common day-to-day invocations. The page also aims to make the underlying Git commands more transparent, with the hope that by explaining what happens under the hood, it may become less confusing when `sync-all` fails.
bash$ ./sync-all pull --rebase
Yes, sync-all does already call `git submodule update` in some occasions already, but its current implementation is far more confusing than it needs to be IMHO :-)
· Under “Overriding pushurl”, same question. Couldn’t that long “git submodule foreach” command be done by sync-all?
yes, it will (even though that specific invocation will be taken core by sync-all in the future, that snippet serves as an example for the versatile 'git submodule foreach' tool everyone working with submodules should at least know about -- it's not that far-fetched that one might want to do something non-standard sync-all doesn't handle)
· Under “Making changes”, this looks hard to me. Is “base” a submodule? Does that mean we have to remember to do some incantations before we modify base?
Actually, we're strongly considering to fold the non-upgradable GHC-specific packages tied to GHC, namely - base - ghc-prim - integer-{gmp,simple} - template-haskell into ghc.git (as was done with testsuite/) as those wouldn't benefit much from remaining an independent (submodule) repo anyway;
What if you forget and make the modifications first? Again, could some of this be automated, at least for the common workflow of pull/push?
for one, if you forget to associate a Git branch before committing on a detached-HEAD, you can simply 'git push origin HEAD:master' If you meant about forgetting to update ghc.git to point to the new commit, then that's actually a feature to avoid *having* to track each single push/commit to master of a submodule to ghc.git's master branch as well; For instance, utils/haddock 'master' is currently one rather unimportant commit[1] ahead of what 'ghc.git' references as its haddock.git commit right now. [1]: http://git.haskell.org/haddock.git/commitdiff/f3c7cd34d066cd40cb4983893165de...
Thanks for the wiki page. One thing missing I noticed is what happens the next time you update your tree, after having checked out master (or a branch) in one of the submodules. Cheers, Simon On 23/03/2014 21:03, Herbert Valerio Riedel wrote:
On 2014-03-23 at 19:53:55 +0100, Simon Peyton Jones wrote:
Do us naïve users need to change our workflow with these submodule changes?
Probably yes... to some extent at least; that's why only haddock.git has been converted for now[1]: to find out empirically what's involved before continuing with the submodule-conversion.
I've tried to describe one possible workflow (for if you need to publish a modification to haddock.git) at
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#Maki...
I hope it makes a bit of sense :-)
IMO, it's quite useful to familiarize oneself with the 'git submodule' family of commands, and especially 'git submodule' and 'git submodule summary', as those two introspection commands allow one to get a better picture in which state the currently cloned GHC working tree's submodules are.
[1]: OTOH, haddock.git is not the first/only proper Git submodule we have so far; so, in some way this isn't much of a change... _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
participants (3)
-
Herbert Valerio Riedel -
Simon Marlow -
Simon Peyton Jones