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

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