Re: [PATCH 10/19] completion: use bash builtins to search for repository
- From
SZEDER Gábor <szeder@ira.uka.de>
- Date
- May 9, 2012, 22:34 UTC
- 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:
Show 17 quoted lines
> 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?