On 2014-04-29 at 12:27:38 +0200, Simon Marlow wrote:
[...]
>>> I think that's fine. As Simon points out, we already have lagging
>>> repo functionality in the form of the submodule links, so the repo on
>>> git.haskell.org can be a pure mirror.
>>
>> Just so I get this right, does "pure mirror" here mean that we don't
>> want users to be able to push to the automatically mirrored repo on
>> git.haskell.org at all, but rather the only way to get any commits into
>> the git.haskell.org mirrored repo would be push it via the GitHub repo?
>>
>> (I'd like that, as it would make the set-up easier and hopefully less
>> confusing, as there'd be only a single data-flow path)
>
> Makes sense to me, but how does that interact with your post-commit
> hook that checks for validity of the submodule updates?
(btw, it's actually a pre-receive/update script, as a post-commit hook
runs to late to be able to reject ref-updates)
The submod-referential-check script would still work, as it would check
that at least at the time a push to ghc.git was done, the respective
submodule commits were present at git.haskell.org
I've asked the GitHub admins to disallow force-pushes on the new repos I
created at github.com/haskell/ as a safety measure (they don't support
disallowing branch-deletion though, so there's still a way to force-push
by workarounding via branch deletion+recreation, but I'd trust the users
we give write-access to[1] to not abuse this loophole)
Moreover, I'd configure the sub-repos at git.haskell.org to never prune
unreachable objects automatically as a short-term measure. This would
allow to manually recover any "lost" commits, and make them reachable
again, even if github.com/haskell already forgot about them.
As for the mirroring itself, this may lag a little bit at first, until I
get the scripting better: right now git.haskell.org would poll
github.com every 10 minutes or so for new commits. Later-on that would
be improved by enabling a post-commit webhook on github to notify
git.haskell.org about new commits to reduce the mirroring latency. I
hope this is enough for now.
Also, I'd like to share the automatic mirroring-workflow with other
packages already living at github.com/haskell, such as containers or
bytestring.
Long story short, the workflow for modifying a core-lib package formerly
living at git.haskell.org would be to
1.) get the commit somehow into the new upstream at github.com[2]
2.) wait a little bit till the commit gets propagated automatically to
git.haskell.org
3.) commit and push the submodule gitlink ref update in ghc.git to
git.haskell.org
Cheers,
hvr
[1]: I've created a 'GHC developers' team in the github.com/haskell org
some time ago, which mirrors the users who have write access to
git.haskell.org; I'd simply assign those to the new repos for
now. So there should be no authorization-regressions.
[2]: We'll provide a convenient way to redirect pushes to
git.haskell.org/packages/$PKG to its real writable upstream repo
I recently learned about Git's
url.<base>.insteadOf
url.<base>.pushInsteadOf
redirection feature, you'd only have to set the redirect rules
once, and then you could 'git clone --recursive' simply using the
canonical http://git.haskell.org URLs, but it would instead go to
github.com for fetch/pushes as instructed. This may be far easier
and more robust than having sync-all rewriting the pushurls.
this would also make it easy, to temporarily switch to github.com,
if git.h.o is down, w/o having to reconfigure all your ghc source
trees, as those rules are a setting that can live in ~/.gitconfig
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
