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:[email protected]] | Sent: 23 March 2014 21:03 | To: Simon Peyton Jones | Cc: [email protected] | 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#MakingchangestoGHCsubmodules> | MakingchangestoGHCsubmodules<https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#MakingchangestoGHCsubmodules> | | 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 [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
