pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack

pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack

[Alexey Dobriyan]

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?

Re: pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack

[Ryan Anderson]

On Fri, Jul 08, 2005 at 11:49:45AM +0400, Alexey Dobriyan wrote:
> 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?

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.

-- 

Ryan Anderson
  sometimes Pug Majere

Re: pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack

[Linus Torvalds]

On Fri, 8 Jul 2005, Alexey Dobriyan wrote:
> 
> 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?

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