Re: "git-send-pack"

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 30, 2005, 20:12 UTC
Message-ID: <Pine.LNX.4.58.0506301302410.14331@ppc970.osdl.org>
In-Reply-To: <Pine.LNX.4.21.0506301403300.30848-100000@iabervon.org>

On Thu, 30 Jun 2005, Daniel Barkalow wrote:

Show 7 quoted lines

> 
> The right solution probably involves getting each pack file you push to
> the mirrors as well as to the master. They'll probably update no less
> frequently than you push, and they should go through a series of states
> which matches the master, so it's not necessary to have anything smart on
> master sending them, and they only have to unpack the files they get (and
> update the refs afterward).

Hmm, yes. That would work, together with just fetching the heads.

It won't _really_ solve the problem, since the pushed pack objects will grow at a proportional rate to the current objects - it's just a constant factor (admittedly a potentially fairly _big_ constant factor) improvement both in size and in number of files.

So the mirroring ends up getting slowly slower and slower as the number of pack files go up. In contrast, a git-aware thing can be basically constant-time, and mirroring expense ends up being relative to the size of the change rather than the size of the repository.

But mirroring just pack-files might solve the problem for the forseeable future, so..

"git-receive-pack" would need to take a flag to tell it to instead of unpacking just check the object instead (ie call "git-unpack-object" with the "-n" flag - it will check that everything looks ok, including the embedded protecting SHA1 hash), and write it out to the filesystem (as it comes in) and then rename it to the right place.

			Linus