SZEDER Gábor [off-list ref] 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).
Thanks.
On Wed, May 09, 2012 at 12:52:49PM -0700, Junio C Hamano wrote:
SZEDER Gábor [off-list ref] writes:
quoted
..., 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?