0

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

（注意我有一个 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.

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

4

1 回答 1

1

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

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

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

除了学术好奇心和/或可能的内部错误之外，您应该停止使用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运行——并且运行得更快、更简单、更容易处理。它也适用于git ls-files所有其他 Git 命令，因为它是在git前端实现的。

于 2020-01-30T08:59:08.663 回答