NOTICE: Gitolite migration is complete.

Herbert Valerio Riedel hvr at
Sat Aug 10 11:06:06 CEST 2013

Hello GHC Devs,

Let me add some details and clarifications to yesterday's
migration completion notice:

On 2013-08-10 at 00:19:53 +0200, Austin Seipp wrote:
> Push access is now restored and Gitolite is in place! This brings some
> nice updates:

>  * There's now access to the 'git' protocol for cloning anonymously.
>    This lets you clone even the biggest repos extremely quickly, and is
>    the fastest method for getting a copy of the tree.

Consequently, if you are a developer (and not behind a firewall that
filters port 9418) you should try out the following assymetric

  ./sync-all -r git:// remote set-url origin
  ./sync-all -r ssh:// remote set-url --push origin

This uses the unauthenticated low-latency git:// protocol for fetching
repository data, and the authenticated encrypted high-latency ssh://
protocol for pushing into the GHC repositories.

This setup has the advantage over using the GitHub GHC mirrors, that the
fetch and push locations are really identical and never out-of-sync
(e.g. if the Git mirroring breaks or lags for some reason)

>  * Firewalled? Cloning over HTTP now uses Smart HTTP support for Git,
>    meaning it should be faster too!
>  * We will soon have Gitweb available, once our CNAME
>    is in place. Eventually we'd like something akin to

Small clarification: Smart HTTP Git transport is only enabled on; The legacy URLs at
are is still served "dumbly".

If you don't want to wait for the DNS CNAME entry, you can fake the DNS
entry to point to, e.g. by

  echo "" >> /etc/hosts

(...and don't forget to remove that entry once the real DNS CNAME entry
is in place) and then just point your browser to

> The following people have had their keys re-added, and should be able
> to push and pull from the new setup.
> [...]

You should all check your current permissions by invoking

  ssh git at info

you should see something like

| hello $USERNAME, this is gitolite 2.3-1 (Debian) running on git
| the gitolite config gives you the following access:
|     @R   W 	ghc
|     @R   W 	ghc-tarballs
|     @R   W 	git-sandbox
|     @R   W 	haddock
| [...]
|     @R   W 	packages/unix
|     @R   W 	packages/vector
|     @R   W 	packages/xhtml
|     @R   W 	testsuite

Please make sure, *YOUR* username shows up in place of $USERNAME, to
find out whether we mixed up your public keys.

(See, if you want
to know more about the meaning of the output)

Note: The current setup denies non-fast-forward and ref-deletion updates
via "git push". This will be relaxed once we reach an agreement over
what the Git heads/tag refs namespace policy shall be (i.e. who is
allowed to create/delete/non-fwd-update heads/tags (and which ones)).

If you want to debug/test 'git push', feel free to push whatever you
like to the 'git-sandbox' repository.

> Please direct any concerns to me, like if you need something off the
> server, need your shell account back, or need commit access.

For technical problems with Trac&Git(olite) itself, please CC me as
well; as I am in a different timezone from Austin, this may help reduce
the response time for solving the issue at hand. Alternatively, you can
also reach us on freenode's #haskell-infrastructure

And finally, the changes resulting from the new Trac commit-hook
integration is worth a separate posting of its own to follow shortly.


More information about the ghc-devs mailing list