On 11/13/2012 09:50 PM, David Aguilar wrote: > On Mon, Nov 12, 2012 at 9:47 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: >> >>> 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? >> >> Yeah, I was also wondering about that. >> >> David? > > I double-checked our configuration and all the parent directories > of those listed in GIT_CEILING_DIRECTORIES are local, > so our particular configuration would not have a performance hit. > > We do have multiple directories listed there. Some of them share > a parent directory. I'm assuming the implementation is simple and > does not try and avoid repeating the check when the parent dir is > the same across multiple entries. > > In any case, it won't be a problem in practice based on my > reading of the current code. OK, so we're back to the following status: some people (including me) are nervous that this change could cause a performance regression, though it seems that the most sensible ways of using the GIT_CEILING_DIRECTORIES feature would not be affected. In favor: Currently, if a directory containing a symlink is added to GIT_CEILING_DIRECTORIES, then GIT_CEILING_DIRECTORIES will not work, git has no way of recognizing that there is a problem, and the only symptom observable by the user is that the hoped-for performance improvement from using GIT_CEILING_DIRECTORIES will not materialize (or will disappear after a filesystem reorg) [1]. Against: The change will cause a performance regression if a slow-to-stat directory is listed in GIT_CEILING_DIRECTORIES. The slowdown will occur whenever git is run outside of a true git-managed project, most nastily in the case of using __git_ps1 in a shell prompt. I don't have a preference either way about whether these patches should be merged. Michael [1] It is also conceivable that GIT_CEILING_DIRECTORIES is being used to *hide* an enclosing git project rather than to inform git that there are no enclosing projects, in which case the enclosing project would *not* be hidden. This is in fact the mechanism by which the problem causes failures in our test suite. But I don't expect that this is a common real-world scenario, and anyway such a failure would be obvious to the user and quickly fixed. -- 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