git git别名导致“权限被拒绝”错误

git aliases causing "Permission denied" error

提问by Alexei Danchenkov

The following commands

以下命令

$ git co -b newbranch
$ git co oldbranch

result in "fatal: cannot exec 'git-co': Permission denied" error.

导致“致命：无法执行‘git-co’：权限被拒绝”错误。

In the same time,

在同一时间，

$ git checkout -b newbranch
$ git checkout oldbranch

and

和

$ sudo git co -b newbranch
$ sudo git co oldbranch

work as expected. Ownership rights for the .git folder are set for the user owning the home folder and 0755/0644 are the mode for .git folder/subfolder/files. There are no git-coscript anywhere in the system (that is an expandable alias to git-checkout, which resides in /usr/libexec/git-core` dir).

按预期工作。.git 文件夹的所有权是为拥有主文件夹的用户设置的，0755/0644 是 .git 文件夹/子文件夹/文件的模式。git-co系统中的任何地方都没有脚本（它是 的可扩展别名git-checkout，位于 /usr/libexec/git-core` 目录中）。

Aliases are defined in .gitconfigof the home folder:

别名.gitconfig在主文件夹中定义：

[alias]
co = checkout

There is no difference in git config -loutput for root or unprivileged user. Still sudo git co oldbranchworks and git co oldbranchdoes not.

git config -lroot 或非特权用户的输出没有区别。仍然sudo git co oldbranch有效，git co oldbranch但没有。

What am I missing?

我错过了什么？

Gentoo / kernel 3.0.6 / git 1.7.3.4

Gentoo / 内核 3.0.6 / git 1.7.3.4

回答by Alexei Danchenkov

The correct answer to this was actually different. Before git runs the aliases it checks the $PATH. In case the directory does not exist, or lacks permissions, git produces the "fatal: cannot exec 'git-co': Permission denied". It does not ever comes to check the aliases so git foobarwill produce the same error.

对此的正确答案实际上是不同的。在 git 运行别名之前，它会检查$PATH. 如果目录不存在或缺少权限，git 会生成"fatal: cannot exec 'git-co': Permission denied". 它永远不会检查别名，因此git foobar会产生相同的错误。

Good people from the git mailing list also reminded me of an stracetool, that can help finding the entry that is returning EACCES, as in: strace -f -e execve git foobar

来自 git 邮件列表的好人也让我想起了一个strace工具，它可以帮助找到返回 EACCES 的条目，如下所示：strace -f -e execve git foobar

The credit goes to Jeff King from the git mailing list. :)

归功于 git 邮件列表中的 Jeff King。:)

回答by Dan Cruz

Is it possible you have inadvertently created a non-executable git-cofile somewhere? I can recreate your situation if I do just that, as demonstrated below.

您是否可能无意中在git-co某处创建了一个不可执行的文件？如果我这样做，我可以重新创建您的情况，如下所示。

$ git --version
git version 1.7.7.1.475.g997a1
$ git config --get-regexp '^alias\.co$'
alias.co checkout
$ git co b1
Switched to branch 'b1'
$ touch $HOME/bin/git-co
$ ls -al $HOME/bin/git-co
-rw-r--r-- 1 user user 0 2011-11-03 12:59 /home/user/bin/git-co
$ git co master
fatal: cannot exec 'git-co': Permission denied
$ for p in $(echo "$PATH" | sed -e 's/:/ /g'); do if [ -f "${p}/git-co" ]; then echo "Found git-co in ${p}"; fi; done
Found git-co in /home/user/bin
$ rm $HOME/bin/git-co
rm: remove regular empty file `/home/user/bin/git-co'? y
$ git co master
Switched to branch 'master'

Another thing you might want to try is enabling trace logging to get more information about what Git is doing. Following is an example:

您可能想尝试的另一件事是启用跟踪日志记录以获取有关 Git 正在执行的操作的更多信息。下面是一个例子：

GIT_TRACE=$HOME/trace.log git co master

You must use absolutepaths if you want to send output to a file. Otherwise, use trueor 1to send output to standard error; e.g. GIT_TRACE=1. The trace.logfile contains:

如果要将输出发送到文件，则必须使用绝对路径。否则，使用true或1将输出发送到标准错误；例如GIT_TRACE=1。该trace.log文件包含：

trace: exec: 'git-co' 'master'
trace: run_command: 'git-co' 'master'
trace: alias expansion: co => 'checkout'
trace: built-in: git 'checkout' 'master'

If you do not see the trace: alias expansion: co=> 'checkout'trace log output, Git is finding a git-cofile in the PATHenvironment variable. Git uses a PATHas follows:

如果您没有看到trace: alias expansion: co=> 'checkout'跟踪日志输出，则 Git 正在环境变量中查找git-co文件PATH。Git使用PATH如下：

1. Start with an empty PATH, saving any "old" PATHfor reference.
2. If the --exec-path=<my git commands path>Git option is found, append <my git commands path>to the PATH.
3. If --exec-path=<my git commands path>was not found and the GIT_EXEC_PATHenvironment variable is set, append this to the PATH.
4. If you called gitusing a relative or absolute path, append the absolute path of the gitexecutable to the PATH.
5. If PATHwas previously defined, append it to the PATH.
6. If PATHwas not previously defined, append /usr/local/bin:/usr/bin:/binto the PATH.

1. 从空开始PATH，保存任何“旧”PATH以供参考。
2. 如果--exec-path=<my git commands path>找到 Git 选项，则附加<my git commands path>到PATH.
3. 如果--exec-path=<my git commands path>未找到并且GIT_EXEC_PATH设置了环境变量，请将其附加到PATH.
4. 如果您git使用相对或绝对路径调用，请将git可执行文件的绝对路径附加到PATH.
5. 如果PATH之前已定义，请将其附加到PATH.
6. 如果PATH之前未定义，则附加/usr/local/bin:/usr/bin:/bin到PATH.

You can use another alias to get Git to tell you what it is setting the PATHenvironment variable to.

您可以使用另一个别名让 Git 告诉您它将PATH环境变量设置为什么。

$ git config --global alias.whatpath '!echo $PATH'
$ git whatpath
/usr/local/libexec/git-core:/home/user/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Then check each directory listed for the existence of a git-cofile. It's not sufficient to do which git-coand assume that if nothing is found that you do not have a git-cofile located in one of the directories in Git's PATH; a file may exist that is not executable and whichwill not display it.

然后检查列出的每个目录是否存在git-co文件。仅做which git-co并假设如果没有发现任何git-co文件，则您在 Git 的目录之一中没有文件是不够的PATH；可能存在不可执行且which不会显示的文件。

回答by MeghaK

Check to see if you have execute permissions on the git aliases. Providing the execute permissions solved this issue for me.

检查您是否对 git 别名具有执行权限。提供执行权限为我解决了这个问题。

I downloaded "git-credential-osxkeychain" and added it to /usr/local/bin and provided the exec rights and could run the command without any issue.

我下载了“git-credential-osxkeychain”并将其添加到 /usr/local/bin 并提供了执行权限，并且可以毫无问题地运行该命令。