On Sat, Oct 20, 2012 at 11:51 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > >> This patch series has the side effect that all of the directories >> listed in GIT_CEILING_DIRECTORIES are accessed *unconditionally* to >> resolve any symlinks that are present in their paths. It is >> admittedly odd that a feature intended to avoid accessing expensive >> directories would now *intentionally* access directories near the >> expensive ones. In the above scenario this shouldn't be a problem, >> because /home would be the directory listed in >> GIT_CEILING_DIRECTORIES, and accessing /home itself shouldn't be >> expensive. > > Interesting observation. In the last sentence, "accessing /home" > does not exactly mean accessing /home, but accessing / to learn > about "home" in it, no? > >> But there might be other scenarios for which this patch >> series causes a performance regression. > > Yeah, after merging this to 'next', we should ask people who care > about CEILING to test it sufficiently. > > Thanks for rerolling. GIT_CEILING_DIRECTORIES was always about trying to avoid hitting them at all; they can be (busy) NFS volumes there. Here's the description from the 1.6.0 release notes: * A new environment variable GIT_CEILING_DIRECTORIES can be used to stop the discovery process of the toplevel of working tree; this may be useful when you are working in a slow network disk and are outside any working tree, as bash-completion and "git help" may still need to run in these places. In 8030e44215fe8f34edd57d711a35f2f0f97a0423 Lars added GIT_ONE_FILESYSTEM to fix a related issue. Do you guys have GIT_CEILING_DIRECTORIES set too? We use GIT_CEILING_DIRECTORIES and I'm pretty sure we don't want every git command hitting them, so this would be a regression when seen from the POV of our current usage of this variable, which would be a bummer. Is there another way to accomplish this without the performance hit? Maybe something that can be solved with configuration? I'd be happy to lend a hand if you guys have some ideas on how we can help keep it fast. Thoughts? Original patches for those just joining us: http://thread.gmane.org/gmane.comp.version-control.git/208102 -- David -- 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