Re: pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack

2005-07-08 Thread 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
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack

2005-07-08 Thread 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
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html