more findings about the gitolite architecture

howto/git.md

@@ -696,10 +696,11 @@ syncing everything.
 
 ## Design
 
-git-rw runs on `cupani.torproject.org` and runs as the git user. Users in the
-gitolite (gid 1504) group can become the git user. The gitolite installation
-is contained inside `/srv/git.torproject.org` with the repositories being found
-in the `repositories` folder there.
+`git-rw.torproject.org`, the writable git repository hosting, runs on
+`cupani.torproject.org` as the git user. Users in the gitolite (gid
+1504) group can become the git user. The gitolite installation is
+contained inside `/srv/git.torproject.org` with the repositories being
+found in the `repositories` folder there.
 
 The gitolite installation itself is *not* from Debian packages. It's a
 manual install, in `/srv/git.torproject.org/gitolite/src`, of an
@@ -724,10 +725,29 @@ because `exportOptions` is set to `GITOLITE` on the `cupani` host. All
 users with a valid LDAP account get their SSH key added to the list
 and only gitolite configuration restricts further access.
 
+When a repository is pushed to, it gets synchronised to the gitweb
+host on a `post-receive` hook
+(`/srv/git.torproject.org/git-helpers/post-receive.d/00-sync-to-mirror`),
+which calls `.../git-helpers/tools/sync-repository` which just
+`rsync`'s the repository over, if and only if the
+`git-daemon-export-ok` flag file is present. If it isn't, an *empty*
+repository (`/srv/git.torproject.org/empty-repository`) is
+synchronized over, deleting the repository from the gitweb mirror.
+
 Access to push to this repository is controlled by the
 `gitolite-admin` repository entry in the gitolite configuration file,
 and not by LDAP groups.
 
+Note that there is a `/srv/git.torproject.org/projects.list` file that
+contains a list of repositories. That file is defined in
+`/srv/git.torproject.org/etc/gitolite.rc` and is, in theory, the
+entire list of projects managed by gitolite. In practice, it's not:
+some (private?) projects are missing in there, but it's not clear why
+exactly (for example, `admin/trac/TracAccountManager` is not in there
+even though it's got the `git-daemon-export-ok` flag and is listed in
+the `gitolite.conf` file). This *might* be because of access controls
+specifications in the `gitolite.conf` file.
+
 ## GitLab migration
 
 As mentioned in the lead, the gitolite/gitweb infrastructure is, as of