Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone

From: James Pickens <jepicken@gmail.com>
Date: Jul 25, 2008, 00:46 UTC
Message-ID: <loom.20080725T004541-298@post.gmane.org>
In-Reply-To: <20080724182813.GA21186@sigill.intra.peff.net>

Jeff King <peff <at> peff.net> writes:

> I agree there are a lot of issues. I am just thinking of the person who
> said they had a >100G repository. But I am also not volunteering to do
> it, so I will let somebody who really cares about it try to defend the
> idea.

If you're referring to me (I mentioned a 144G CVS repo), then let me clarify a couple of things:

1.  Probably more than 50% of the 144G is crud that should never have
been checked in, but I have some undisciplined coworkers who like to
blindly check in everything in their work trees.  If/when we moved to
git, I would get rid of all that crud.  I'm also thinking about throwing
out a lot of the history, since those same undisciplined coworkers like
to use empty and/or useless log messages, so a lot of the history isn't
very valuable anyways.

2.  Git of course will store the remaining ~70G much more efficiently
than CVS.  I think git will be especially better than CVS for this repo,
because it contains many instances of the same file(s) being checked in
in multiple directories.

I expect the git repo size to be less than 7G. In addition, all our work is done on site on nfs, so we can use clone -s to avoid copying the whole 7G.

To sum it up, sparse cloning would not be important to me.

James