On Tue, 9 Feb 2010, Stephen Boyd wrote: > --thin:: > - Spend extra cycles to minimize the number of objects to be sent. > - Use it on slower connection. > + Spend extra cycles minimizing the number of sent objects. > + Use it with a slow connection. Both the old and the new text are bollocks. There is no extra cycles involved here. And linking this to a slow connection is misleading. The point of --thin is to create a pack containing delta objects while excluding the base objects they depend on when those objects are known to exist in the receiver's repository already. Because base objects are usually significantly bigger than delta objects, this results in a large reduction in the amount of data to transfer. However we don't allow a pack with delta objects referencing base objects to be stored in a Git repository if those base objects are not part of the same pack for robustness reasons. Therefore, when a thin pack is transferred via the git protocol, the receiving end must "fatten" the pack by appending those missing base objects for that pack to be complete and valid. This results in somewhat suboptimal object storage on the receiving end due to some object duplications. Of course a simple gc will fix that. These days --thin is always the default for a fetch. We used to think that --thin might not be the best thing to do on a push given that the receiving end is typically a central server in that case and keeping storage low on a central server should be preferred. But --thin turned out to be re-enabled by default for pushes by mistake on a few occasions when the affected code has been reworked. No idea what state it is now, and I don't think that makes such a difference on the server in the end. Nicolas -- 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