为什么 git ls-remote 和 git ls-files 因某些相对路径而失败？

Question

假设我在 ~/dev/company/products/company-common 有一个 git 仓库。从其他几个文件系统位置，我尝试在该 repo 上执行 ls-files 或 ls-remote。所有的工作，除了最后一个。最后一个不起作用的原因可能是什么？

(N.B。我有一个 2 行 bash 提示：

user@machine:products (~/dev/company/products)
$ git ls-remote company-common HEAD 
f25b342b384de1b82cb67b6f530303b4fac37ff0    HEAD

user@machine:products (~/dev/company/products)
$ git ls-remote ../products/company-common HEAD
f25b342b384de1b82cb67b6f530303b4fac37ff0    HEAD

user@machine:products (~/dev/company/products)
$ git ls-remote ../../company/products/company-common HEAD
f25b342b384de1b82cb67b6f530303b4fac37ff0    HEAD

user@machine:products (~/dev/company/products)
$ cd gui

user@machine:gui [master] (~/dev/company/products/gui)
$ git ls-remote ../company-common HEAD
f25b342b384de1b82cb67b6f530303b4fac37ff0    HEAD

user@machine:gui [master] (~/dev/company/products/gui)
$ cd dummy/

user@machine:dummy-application [master] (~/dev/company/products/gui/dummy)
$ git ls-remote ../../company-common HEAD
fatal: '../../company-common' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

None 所涉及的目录是符号链接。我只显示了每个命令的一行输出（最后一条除外）

Answer 1

有趣的是 git ls-remote 在这里完全有效。

您传递给 git ls-remote 的第一个参数应该是 URL（https://host/...、ssh://git@github.com/... 等）或遥控器的名称（通常是 origin).但是，Git 接受本地文件系统路径代替 file://... URLs.

当 Git 做最后一个把戏时，它似乎有点奇怪和不一致。在我的实验中，我得到了一些不同的行为，但它仍然很奇怪。

除了学术上的好奇and/or可能的内部错误，你应该在这里停止使用git ls-remote并直接使用git rev-parse。如果你想从当前存储库中获取修订散列 ID，只需运行 git rev-parse:

git rev-parse HEAD

例如。如果您想从文件系统位置 X 中的其他 Git 存储库获取一个，请使用：

git -C X rev-parse HEAD

例如。这表现得很好——与你和我在这里看到的 git ls-remote 的奇怪结果不同，-C 参数在 rev-parse 期间使 Git 在内部 chdir——并且运行s 更快，更简单，更容易处理。它也适用于 git ls-files 和所有其他 Git 命令，因为它是在 git 前端实现的。

为什么 git ls-remote 和 git ls-files 因某些相对路径而失败？

Why do git ls-remote and git ls-files fail with some relative paths?

linux

bash

git

git-ls-files

git-ls-remote