Matt Korostoff <[email protected]> writes:
> In some system configurations there is a bug with the
> __git_remotes function. Specifically, there is a problem
> with line 415, `test -d "$d/remotes" && ls -1 "$d/remotes"`.
> While `test -d` is meant to prevent listing the remotes
> directory if it does not exist, in some system, `ls` will
> run regardless.
What's "some system"?
Is this a platform's bug (e.g. "test -d" does not work correctly)?
Is this an configuration error of user's Git repository?
Is this something else?
I _think_ you would see the problem if $d/remotes is a directory
whose contents cannot be listed (e.g. "chmod a= $d/remotes"), and
that would not be a platform's bug (i.e. "test -d" would happily say
"Yes there is a directory", and "ls" would fail with "Permission
denied"). But I wonder if we rather want the user to notice that
misconfiguration so that the user can correct it, instead of hiding
the error message from "ls".
> This results in an error in which typing `git push or` + `tab`
> prints out `ls: .git/remotes: No such file or directory`.
> This can be fixed by simply directing stderror of this line
> to /dev/null.
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 2fece98..72251cc 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -412,7 +412,7 @@ __git_refs_remotes ()
> __git_remotes ()
> {
> local i IFS=$'\n' d="$(__gitdir)"
> - test -d "$d/remotes" && ls -1 "$d/remotes"
> + test -d "$d/remotes" && ls -1 "$d/remotes" 2>/dev/null
> for i in $(git --git-dir="$d" config --get-regexp 'remote\..*\.url'
> 2>/dev/null); do
> i="${i#remote.}"
> echo "${i/.url*/}"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
