Nicolas Pitre <nico@xxxxxxx> wrote: > On Sun, 9 Sep 2007, Shawn O. Pearce wrote: > > > Originally I started this patch out thinking that --no-thin was > > the default for git-push and that therefore this was almost a > > no-brainer change. Then I found out it isn't the default, so now > > I'm not so sure about the value of this particular patch. > > How come it isn't the default? Well, according to git-blame this particular line dates all the way back to Linus' rewrite of git-push into C (755225de6ce4). In every commit that has since touched that "static int thin" declaration they all left it as "thin = 1". Apparently --thin has always been the default for git-push, ever since Junio made it the default (84f11a4335), which is way back when git-push was still git-push.sh. Junio's change to make --thin the default is all the way back in 2006-03-25, which is months before you taught index-pack how to do the --fix-thin logic (636171cb) in 2006-10-25. > Last time I fiddled in that area, I explicitly avoided enabling thin > packs on push for the following reasons: Yea, that was my recollection too. Which is why I just assumed all though that patch's developemnt that thin was off by default, and was actually surprised when I found it that thin was *on* by default. I'm suspecting you submitted a patch to disable thin by default in git-push but that the patch got dropped by Junio by accident. > 1) pushes happen less often than fetches, so the bandwidth saving is > much less visible in that case overall. > > 2) thin packs have to be complemented with missing delta bases to be > valid, so many received thin packs will take more disk space. > > 3) the bother of repacking should be distributed amongst "clients" > i.e. fetchers and pushers as much as possible, and not the server > being fetched or pushed, to keep disk and CPU usage low on the > server. > > This is why a fetch should get thin packs but a push should not. Yes. I agree with you completely. I'm sending a patch for it right now to Junio. I'll quote your reasons above, because it is a very good summary of why it should be this way. -- Shawn. - 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
