On 10/29/2012 01:15 AM, David Aguilar wrote: > 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. I would certainly withdraw the patch series if it causes a performance hit. The log message of the original commit (0454dd93bf) described the following scenario: a /home partition under which user home directories are automounted, and setting GIT_CEILING_DIRECTORIES=/home to avoid hitting /home/.git, /home/.git/objects, and /home/objects (which would attempt to automount those directories). I believe that this scenario would not be slowed down by my patches. How do you use GIT_CEILING_DIRECTORIES that the proposed changes cause a slowdown? > Is there another way to accomplish this without the performance hit? > Maybe something that can be solved with configuration? Without doing the symlink expansion there is no way for git to detect that GIT_CEILING_DIRECTORIES contains symlinks and is therefore ineffective. So the user has no warning about the misconfiguration (except that git runs slowly). On 10/29/2012 02:42 AM, Junio C Hamano wrote: > Perhaps not canonicalize elements on the CEILING list ourselves? If > we make it a user error to put symlinked alias in the variable, and > document it clearly, wouldn't it suffice? There may be no other choice. (That, and fix the test suite in another way to tolerate a $PWD that involves symlinks.) Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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