It's mirroring.
The way that kernel.org works is that there is one master site, which is
not actually running any public services at all. That's the one that
people who have write access can ssh into, and rather than run any public
services, it runs the security-conscious things, like the secure logins
and the automated signing scripts.
The actual _public_ sites are just mirrors, with just rsync between the
things. All to keep the services on the master site minimal.
But because the public sites just mirror using rsync, and aren't really
aware of git repositories etc at that stage, what can happen is that a
mirroring is on-going when Junio does a push, and then the changes to the
"refs/" directory might get rsync'ed before the "object/" directory does,
and you end up with the public sites having references to objects that
don't even _exist_ on those public sites any more.
When they then run git-daemon, git-deamon will basically see a corrupt git
archive, and not expose those "broken" refs at all. Which explains what
you see.
And once the mirroring completes, the issue just goes away, which explains
why it just magically works five minutes later.
If the public sites used git itself to synchronize git repositories,
they'd never see anything like this (because git itself will only write
the new refs after it has actually updated the data). But since the thing
needs mirroring for non-git uses too, and since rsync generally _works_
apart from the slight race-condition issue, that's what it just uses.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
