Re: basics... when reading docs doesn't help

[Theodore Tso <tytso@mit.edu>]

On Fri, Mar 30, 2007 at 12:13:02AM +0200, Guennadi Liakhovetski wrote:
> On Thu, 29 Mar 2007, J. Bruce Fields wrote:
> > Though actually on a second look, clone -l -s produces something that's
> > only 377M.  I hadn't realized how much space the build output takes up.
> > So judging from du the 1.5G Guennadi Liakhovetski mentions above seems
> > to break down into something like:
> > 
> > 	330M .git
> > 	380M working tree
> > 	750M build output

Hmm.... That doesn't look right.  My packed .git directory is 156 megs
(using post git 1.5 and repack.usedeltabaseoffset=true and
core.legacyheaders=false).

My working tree is 287M, and my build output (size of build tree minus
sources) is 1055M.   (This will vary based on .config options, obviously).

The point though is the size of the .git tree is in the noise compared
to the size of the object files.  I do share the .git repository
between trees; in fact I have a standard "base" repository which is
just a mirror of Linus's tree, and my other kernel repositories have
an .git/objects/info/alternates file which points at the base
repository for maximal sharing.

I could try to share the sources where the source files are identical,
but quite frankly, it's just never been worth the effort.  After all,
when you have a 100gig laptop drive, 287 megs isn't that much, and
it's noise compared to the size of my object files.

> Strange. Is my git 1.4.0 criminally broken? I have a clone of Linus' tree 
> on a USB disk on ext3 without any objects, which I just cloned at some 
> point and then did a couple of pulls from the same source. 

You really, really, *REALLY* want to upgrade to at least git 1.5.0.
It's is *so* much better than git 1.5.0, and it's a lot easier to make
sure your repository is kept packed, using "git gc".  

						- Ted