* Disabling Delta Compression on a fetch
@ 2011-12-08 17:34 Todd Rinaldo
2011-12-08 20:10 ` Junio C Hamano
2011-12-08 20:14 ` Jeff King
0 siblings, 2 replies; 3+ messages in thread
From: Todd Rinaldo @ 2011-12-08 17:34 UTC (permalink / raw)
To: git
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.
All 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.
The solution I've come up with is to set pack.window=0 in /etc/gitconfig on the gitorious server.
I 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.
My question is: Are there are any unintended consequences of this approach anyone can think of?
Thanks,
Todd Rinaldo
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Disabling Delta Compression on a fetch
2011-12-08 17:34 Disabling Delta Compression on a fetch Todd Rinaldo
@ 2011-12-08 20:10 ` Junio C Hamano
2011-12-08 20:14 ` Jeff King
1 sibling, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2011-12-08 20:10 UTC (permalink / raw)
To: Todd Rinaldo; +Cc: git
Todd Rinaldo <toddr@cpanel.net> writes:
> The solution I've come up with is to set pack.window=0 in /etc/gitconfig on the gitorious server.
Wouldn't setting core.bigfilethreshold be a more appropriate solution?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Disabling Delta Compression on a fetch
2011-12-08 17:34 Disabling Delta Compression on a fetch Todd Rinaldo
2011-12-08 20:10 ` Junio C Hamano
@ 2011-12-08 20:14 ` Jeff King
1 sibling, 0 replies; 3+ messages in thread
From: Jeff King @ 2011-12-08 20:14 UTC (permalink / raw)
To: Todd Rinaldo; +Cc: git
On Thu, Dec 08, 2011 at 11:34:26AM -0600, Todd Rinaldo wrote:
> All 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.
>
> The solution I've come up with is to set pack.window=0 in
> /etc/gitconfig on the gitorious server.
An alternative is to mark the binary files as "-delta" with
gitattributes on the server. Then you will get the benefits of delta
compression for other files without bothering to try the binary files.
Note that git won't read the gitattributes file out of the tree in a
bare repository, so these attributes should go either in
$REPO/info/attributes (if they are repo-specific), or in
/etc/gitattributes (if they are in many repos).
I.e., something like:
echo '*.bin -delta' >/etc/gitattributes
Also, before any of that, make sure that the upstream repos are fully
packed. Git will not try to delta two objects coming from the same pack
(since it will already have tried when they were entering the pack).
That by itself might be enough to solve your problem without any other
configuration.
> My question is: Are there are any unintended consequences of this
> approach anyone can think of?
Other than trading bandwidth, you are also trading space on the client
side, since each client will store the resulting pack.
-Peff
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-12-08 20:14 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-08 17:34 Disabling Delta Compression on a fetch Todd Rinaldo
2011-12-08 20:10 ` Junio C Hamano
2011-12-08 20:14 ` Jeff King
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).