Re: git-pull from git.git - no remote ref for pu or next?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, 12 Dec 2006, Randal L. Schwartz wrote:

> >>>>> "Randal" == Randal L Schwartz <merlyn@xxxxxxxxxxxxxx> writes:
> 
> Randal> I just got this on this morning's git-fetch:
> 
> Randal>     error: no such remote ref refs/heads/pu
> Randal>     error: no such remote ref refs/heads/next
> Randal>     Fetch failure: git://git.kernel.org/pub/scm/git/git.git
> 
> Randal> Here's my remotes/origin:
> 
> Randal>     URL: git://git.kernel.org/pub/scm/git/git.git
> Randal>     Pull: master:origin
> Randal>     Pull: man:man
> Randal>     Pull: html:html
> Randal>     Pull: +pu:pu
> Randal>     Pull: +next:next
> 
> And then it mysteriously fixed itself a few minutes later.
> Is there some sort of publishing failure, or intermittent race condition?

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]