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 -- 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
