[英]Why do git ls-remote and git ls-files fail with some relative paths?
Suppose I have a git repo at ~/dev/company/products/company-common
.假设我在
~/dev/company/products/company-common
有一个 git repo。 From several other filesystem location I try to execute ls-files
or ls-remote
on that repo.从其他几个文件系统位置,我尝试在该存储库上执行
ls-files
或ls-remote
。 All work, except for the last one.所有的工作,除了最后一个。 What could be a reason the last one doesn't work?
最后一个不起作用的原因可能是什么?
(NB I have a 2-line bash prompt): (注意我有一个 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 of the directories involved is a symlink.所涉及的目录都不是符号链接。 I've only shown one line of output from each command (except for the last one)
我只显示了每个命令的一行输出(最后一个除外)
The interesting thing is that git ls-remote
works at all here.有趣的是
git ls-remote
在这里完全有效。
The first argument you pass to git ls-remote
should be a URL ( https://host/...
, ssh://git@github.com/...
, and so on) or the name of a remote (typically origin
).您传递给
git ls-remote
的第一个参数应该是 URL( https://host/...
、 ssh://git@github.com/...
等)或远程名称(通常origin
)。 However, Git accepts local file system paths in place of file://...
URLs.但是,Git 接受本地文件系统路径来代替
file://...
URL。
When Git does that last trick, it seems to do it somewhat weirdly and inconsistently.当 Git 执行最后一个技巧时,它似乎有些奇怪且不一致。 In my experiments I got somewhat different behavior, but it was still weird.
在我的实验中,我得到了一些不同的行为,但仍然很奇怪。
Aside from academic curiosity and/or possible internal bugs, you should just stop using git ls-remote
here and use git rev-parse
directly.除了学术好奇心和/或可能的内部错误之外,您应该在这里停止使用
git ls-remote
并直接使用git rev-parse
。 If you want to get a revision hash ID from the current repository, just run git rev-parse
:如果要从当前存储库获取修订哈希 ID,只需运行
git rev-parse
:
git rev-parse HEAD
for instance.例如。 If you want to get one from some other Git repository in file system location X, use:
如果您想从文件系统位置 X 的其他 Git 存储库获取一个,请使用:
git -C X rev-parse HEAD
for instance.例如。 This behaves well—unlike the odd results you and I are seeing for
git ls-remote
here, the -C
argument makes Git internally chdir
for the duration of the rev-parse—and runs faster and is simpler and easier to deal with.这表现得很好——不像你和我在这里看到的
git ls-remote
奇怪的结果, -C
参数使 Git 在 rev-parse 期间在内部chdir
运行得更快,更简单,更容易处理。 It works for git ls-files
and all other Git commands too, since it is implemented in the git
front end.它也适用于
git ls-files
和所有其他 Git 命令,因为它是在git
前端实现的。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.