pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack

Being a happy user of

	$ cat ./rsync-linus
	#!/bin/sh -x

	cd linux-linus
	rsync -avz --progress \
	        rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
	        .git/

I'm confused now. This pack file is ~60M in size. Will rsync download another 60M next time? What command should I use now to a) get latest and greatest and b) be nice with my traffic?

On Fri, Jul 08, 2005 at 11:49:45AM +0400, Alexey Dobriyan wrote:

You won't need to download another 60M next time.

Run this:
	cd linux-linus
	du -sh .
	git-prune-packed
	du -sh .

You should see a nice drop i space used, as that one big "pack" file is now taking the place of almost every object in the kernel repository.

In the future, you'll just download new packs as Linus generates them. I suspect objects will trickle in as well, but an occassional git-prune-packed will tidy things back up.

The packs internally use a delta-based algorithm to save huge amounts of space, and for speed of daily use, the standalone objects are still in use.

On Fri, 8 Jul 2005, Alexey Dobriyan wrote:

Your existing command should work fine.

You may (or may not) want to use the "--delete" argument to the rsync, which will remove any old objects as they get packed. That won't change your network traffic, but will just keep your disk usage down (and may make rsync a bit more efficient).

And no, the way I'm setting up the kernel repo is that I won't re-pack the _whole_ archive next time around, I'll only create a new incremental pack. So next time a "git repack" happens, you'll see a new pack, probably in the couple-of-megabytes size range (depending on how much work has done on, of course), and the old pack you already downloaded will continue to contain the older history.

Depending on how well - or badly - the incremental packing ends up working, I _may_ end up doing a full, non-incremental pack at some point, but that would be something that happens just a couple of times a year, so then you'd get to do one big update every once in a while.

But I'm hoping that the incrementals work well enough that I literally need to do that maybe once a year or something (replacing 50 incrementals with one new big complete re-pack). Or maybe the incrementals work so well that we don't need to do that at all.

So this "ugh, a new 60MB pack" thing should be something that happens quite infrequently.

		Linus