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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html