From: SZEDER Gábor <szeder@ira.uka.de>
Date: Wed, 09 May 2012 22:34:44 GMT
Subject: Re: [PATCH 10/19] completion: use bash builtins to search for repository
Message-ID: <20120509223444.GH6958@goldbirke>
In-Reply-To: <7v62c5rv1q.fsf@alter.siamese.dyndns.org>

On Wed, May 09, 2012 at 12:52:49PM -0700, Junio C Hamano wrote:
> SZEDER Gábor <szeder@ira.uka.de> writes:
> 
> > ..., this
> > search is not that thorough either, as it doesn't check whether the
> > found '.git' directory or the directory pointed to by a gitfile is a
> > valid '.git' repository.
> > ...
> > Of course, stat()ing in C is much faster than in bash, so there is a
> > point when bash builtins will be slower than '$(git rev-parse
> > --git-dir)' despite all the fork()s+exec() overhead.
> 
> I'd feel safer if this new logic were an opt-in feature, at least in the
> beginning, with these pros-and-cons summarized near the beginning of the
> file to let the users choose if they want to use "exactly matches the
> command the prompt script is trying to help" version (i.e. rev-parse) vs
> "matches most of the time and faster under these conditions" version
> (i.e. the new logic).

I'm not sure what you mean by opt-in.  It's already opt-in in the
sense that users have to set $GIT_DISCOVERY_ACROSS_FILESYSTEM to
enable this logic.  Or do you mean that
$GIT_DISCOVERY_ACROSS_FILESYSTEM should not implicitly enable this
logic, but it should be controlled by a new dedicated variable?