Почему git ls-remote и git ls-файлы терпят неудачу с некоторыми относительными путями? - PullRequest
0 голосов
/ 30 января 2020

Предположим, у меня репо 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.

Ни один из задействованных каталогов не является символической ссылкой , Я показал только одну строку вывода для каждой команды (кроме последней)

1 Ответ

1 голос
/ 30 января 2020

Интересно то, что git ls-remote здесь вообще работает.

Первый аргумент, который вы передаете git ls-remote, должен быть URL (https://host/..., ssh://git@github.com/... и т. Д.) Или имя удаленного (обычно origin). Однако Git принимает пути локальной файловой системы вместо file://... URL-адресов.

Когда Git делает этот последний трюк, кажется, что он делает это несколько странно и непоследовательно. В моих экспериментах у меня было несколько иное поведение, но оно все еще было странным.

Помимо любопытства Academi c и / или возможных внутренних ошибок, вы должны просто прекратить использовать git ls-remote здесь и использовать git rev-parse напрямую , Если вы хотите получить ревизию ha sh ID из текущего репозитория, просто запустите, например, git rev-parse:

git rev-parse HEAD

. Если вы хотите получить один из другого Git репозитория в расположении файловой системы X, используйте:

git -C X rev-parse HEAD

, например. Это ведет себя хорошо - в отличие от странных результатов, которые вы и я здесь наблюдаем для git ls-remote, аргумент -C делает Git внутренне chdir на время повторного анализа - и работает быстрее, и его проще и проще иметь дело с. Он работает также для git ls-files и всех других команд Git, поскольку он реализован в интерфейсе git.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...