{"thread":{"id":"29110","subject":"Disabling Delta Compression on a fetch","startedAt":"2011-12-08T17:34:26Z","lastAt":"2011-12-08T20:14:43Z","messageCount":3,"participants":["Todd Rinaldo","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"180604","messageId":"070681D4-F87B-435E-8A3B-144E59DE722B@cpanel.net","threadId":"29110","inReplyTo":null,"subject":"Disabling Delta Compression on a fetch","fromName":"Todd Rinaldo","fromEmail":"toddr@cpanel.net","sentAt":"2011-12-08T17:34:26Z","receivedAt":"2011-12-08T17:34:26Z","isPatch":false,"sender":{"key":"toddr@cpanel.net","avatar":"https://gravatar.com/avatar/4ee23baee1044d8a3d1d821112d49aaa97976404be3ef6afa42c5bc72f660a28?d=mp&s=160"},"body":"We run an internal gitorious server with many repos on it. Due to legacy issues, some of the repos are rather bloated with large binaries. When several changes happen and are pushed to the gitorious repo and then are later pulled back (fetch and pull) to other clones, we get a broken connection while the gitorious side is generating Delta compression. \n\nAll of the git communication happens on 1 subnet all connected by a single gigabit switch. As I see it, the Delta Compression is actually a performance degradation in our environment.\n\nThe solution I've come up with is to set pack.window=0 in /etc/gitconfig on the gitorious server. \n\nI realize our need is uncommon. I realize by doing this, I am trading increased bandwidth in exchange for starting the send sooner. When I read the documentation for pack.window, it seems more a side effect than the original intent that this variable disables Delta Compression when set to 0.\n\nMy question is: Are there are any unintended consequences of this approach anyone can think of? \n\nThanks,\nTodd Rinaldo\n"},{"id":"180614","messageId":"7vvcpqhlj3.fsf@alter.siamese.dyndns.org","threadId":"29110","inReplyTo":"070681D4-F87B-435E-8A3B-144E59DE722B@cpanel.net","subject":"Re: Disabling Delta Compression on a fetch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-12-08T20:10:40Z","receivedAt":"2011-12-08T20:10:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Todd Rinaldo <toddr@cpanel.net> writes:\n\n> The solution I've come up with is to set pack.window=0 in /etc/gitconfig on the gitorious server. \n\nWouldn't setting core.bigfilethreshold be a more appropriate solution?\n"},{"id":"180615","messageId":"20111208201443.GA8035@sigill.intra.peff.net","threadId":"29110","inReplyTo":"070681D4-F87B-435E-8A3B-144E59DE722B@cpanel.net","subject":"Re: Disabling Delta Compression on a fetch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-12-08T20:14:43Z","receivedAt":"2011-12-08T20:14:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 08, 2011 at 11:34:26AM -0600, Todd Rinaldo wrote:\n\n> All of the git communication happens on 1 subnet all connected by a\n> single gigabit switch. As I see it, the Delta Compression is actually\n> a performance degradation in our environment.\n> \n> The solution I've come up with is to set pack.window=0 in\n> /etc/gitconfig on the gitorious server. \n\nAn alternative is to mark the binary files as \"-delta\" with\ngitattributes on the server. Then you will get the benefits of delta\ncompression for other files without bothering to try the binary files.\n\nNote that git won't read the gitattributes file out of the tree in a\nbare repository, so these attributes should go either in\n$REPO/info/attributes (if they are repo-specific), or in\n/etc/gitattributes (if they are in many repos).\n\nI.e., something like:\n\n  echo '*.bin -delta' >/etc/gitattributes\n\nAlso, before any of that, make sure that the upstream repos are fully\npacked. Git will not try to delta two objects coming from the same pack\n(since it will already have tried when they were entering the pack).\nThat by itself might be enough to solve your problem without any other\nconfiguration.\n\n> My question is: Are there are any unintended consequences of this\n> approach anyone can think of?\n\nOther than trading bandwidth, you are also trading space on the client\nside, since each client will store the resulting pack.\n\n-Peff\n"}]}