On Mon, 23 Sep 2013 10:10:24 -0500 John McKown <john.archie.mck...@gmail.com> wrote:
> I use git to help me synchronize my files between my work machine and > home machine (both Linux based). The bare repository is accessed from > my work machine via SSH. On my home machine, it is on an NFS server. > As an aside, the work machine accesses the NFS server via the home > machine via SSH, not directly from the NFS server. > > I noticed when I do a "git pull", git will apparently recompress the > data before sending it. This makes sense to me when it is not local, > i.e. from my work machine, in order to decrease the number of bytes > transmitted. But it doesn't make sense at all when the repository is > local (on the local HD or NFS mounted) because the data is now coming > into the machine twice. First to recompress it, then to transfer it > into the working directory. > > Now, on my internal gig-ethernet network, this is likely not a big > deal. But I am wonder if it would be a good idea to mention this to > the developers. IOW, are there many people who use a bare repository > over a _slow_ NFS link? Or is it so rare that it would not be worth > using up their time? What's the URL you're using to access the repository on NFS? "The trick" is that if you're using the explicit "file://" scheme Git spawns two processes which then communicate even if this happens on the local host. Conversely, if you're using just a regular (full) Unix pathname, like /a/path/to/the/repository, Git tries to be more clever when accessing it, and even does hardlinking where applicable. Not sure this makes sense for your situation though... -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
