HEADS-UP: new server-side validation git hook for submodule updates & call-for-help

[Herbert Valerio Riedel]

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'