Re: [PATCH v3 0/8] Fix GIT_CEILING_DIRECTORIES that contain symlinks

On 10/29/2012 01:15 AM, David Aguilar wrote:

On Sat, Oct 20, 2012 at 11:51 PM, Junio C Hamano [off-list ref] wrote:

quoted

Michael Haggerty [off-list ref] writes:

quoted

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?

quoted

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@alum.mit.edu
http://softwareswirl.blogspot.com/