Sometime I found myself re-cloning entirely a repository, as example the Linux tree, instead of repackaging my local copy. The reason is that the published Linux repository is super compressed and to reach the same level of compression on my local copy I would need to give my laptop a long night running. So it happens to be just faster to re-clone the whole thing by upstream. Also repackaging a big repo in the optimal way is not so trivial, you need to understand quite advanced stuff like window depth and so on and probably the pack parameters used upstream are easily better then what you could 'guess' trying yourself. Or simply you don't have enough RAM as would be needed. On the other end it would be interesting to know, before to start the new clone, what is the real advantage of this, i.e. what is the repository size upstream. So I would like to ask if anyone would consider useful: - A command like 'git info' or something like that that prints size of local and upstream repository (among possibly other things) - An option like 'git repack --clone' to instruct git to download and use current upstream packs instead of trying to recreate new ones. Marco - 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
