Hello Johan, On 2014-03-18 at 19:17:55 +0100, Johan Tibell wrote:
Lets give some example workflows for working with submodules. Here's what I think a raw (i.e. no sync-all) update to base will look like. Please correct me if I'm wrong.
# Step 1: cd ~/src/ghc/libraries/base # edit some_file git add some_file git commit -m "Commit to base repo" git push # push update to base to git.haskell.org
'git push' w/o a refspec will only work, if the HEAD isn't detached you'd rather have to invoke something like 'git push origin HEAD:ghc-head'[1] (or have a tracked branch checked out)
# Step 2 cd ~/src/ghc git add libraries/base git commit -m "Have GHC use the new base version" git push # push update to ghc to git.haskell.org
Failure modes include:
* Forgetting step 2: the ghc repo will point to a slightly older base next time someone checks it out. Fixing things when in this state: just perform step 2.
that's brings up an interesting question (that was also mentioned on #ghc already): Are there cases when it is desirable to point to an older commit on purpose? (one use-case may be, if you want to rollback ghc.git to some older commit to unbreak the build w/o touching the submodule repo itself) (somewhat related feature: "git submodule update --remote")
* Forgetting `git push` in step 1. the ghc repo will point to a base commit that doesn't exist (except on some developers machine). Fixing things when in this state: the developer who forgot to `git push` in step 1 needs to do that.
Actually, the new server-side hook will reject (for non-wip/ branches at least) a ghc.git commit which would result in a submod-ref pointing to a non-existing commit, so this one's covered already.
How could sync-all help us:
* sync-all push could push all repos, preventing failure case 2 above.
(as I wrote, this can't happen thanks to the new hook script) However, see man-page for "git push --recurse-submodules"
The second interesting workflow involving pulling new changes. This is what the raw (i.e. no sync-all) workflow will look like:
cd ~/src/ghc git pull git submodule update
Failure modes include:
* Forgetting the `submodule update` and then doing e.g. `git commit -am "some compile commit"`, reverting the pointer to e.g. base to whatever older version the developer was using. No commits are lost (nothing changes in the base repo), but the ghc repo will point to an older commit.
How could sync-all help us:
* sync-all pull could always run `submodule update`.
The server-side check that Herbert added will make sure that the failure mode cannot happen, as you explicitly have to say in the commit message that you updated a submodule.
I think if base was folded into ghc.git very few people would have to deal with submodules.
if 'base' remains tightly coupled to ghc internals, that might be indeed be the easiest solution; I'm just not sure how the big base-split will be affected by folded-into-ghc base. Also, supporting a sensible 'cabal get -s base' will require a bit more work (or we'd have to remove the ability for that again -- not that it is of much use anyway) PS: I'm wondering if the next-gen 'sync-all' couldn't be simply realised by defining a set of git aliases[2]; e.g. it's rather commond to have a 'git pullall' alias defined for combining the effect of 'git pull' and 'git submodule update' into one alias[3] Cheers, hvr [1]: occurences of 'ghc-head' will most likely be renamed to 'master' as that's more consistent with GHC HEAD being 'master' in ghc.git as well [2]: https://git.wiki.kernel.org/index.php/Aliases [3]: git config alias.pullall '!git pull && git submodule update --init --recursive'