Git не удается клонировать репозиторий из интерфейса webdav ownCloud

У меня есть несколько личных репозиториев git в моем собственном облаке. Я могу клонировать его с 2 машин Ubuntu и ПК с Windows, открыв URL-адрес webdav ownClouds: http://myserver.a/remote.php/webdav/repos/repo.git

Недавно я установил Arch Linux с git версии 1.8.1.5, и он выдал следующее сообщение об ошибке: fatal: http://myserver.a/remote.php/webdav/repos/repo.git/info/refs?service=git-upload-pack не найдено: вы запускали git update-server-info на сервере?

Я добавил хук после обновления, в конце концов он работает на других моих машинах. Сервер error.log сообщает 404, когда git запрашивает ...info/refs?service...

Ubuntu git 1.7 запрашивает тот же URL-адрес с сервера. Но после получения кода ошибки 404 он запрашивает .../info/refs HTTP/1.1 и завершается успешно с кодом 200.

Итак, почему более новый git терпит неудачу и как я могу это исправить?


git owncloud webdav
person namnor    schedule 05.03.2013    source источник
comment
ты решил проблему? у меня точно такой же сейчас.   -  person mincos    schedule 17.04.2013
comment
Нет, к сожалению, я этого не сделал. Вместо этого я теперь размещаю свои репозитории git через стандартную папку WebDAV с веб-сервером apache.   -  person namnor    schedule 27.05.2013

Ответы (3)


arrow_upward
5
arrow_downward

Все ?service=... связано с интеллектуальной поддержкой HTTP в git, представленной в 1.6.6. Это намного эффективнее, чем традиционная поддержка HTTP, но требует запуска специального бинарного файла CGI на веб-сервере и не работает с WebDAV.

IMO, в любой неповрежденной реализации WebDAV его следует игнорировать, но, по-видимому, ownCloud считает, что это часть имени файла или что-то в этом роде, и поэтому выдает ошибку. Возможно, имеет смысл поговорить об этом с разработчиками ownCloud.

В более старых версиях git возвращался к URL-адресу без этого суффикса, но у этого были свои проблемы. Итак, второй запрос был удален в 1.8.0, и была введена новая опция, которую вы можете использовать для отключения умного HTTP и использования старого URL напрямую (это должно решить проблему). Это работает, например, так:

GIT_SMART_HTTP=0 git fetch

Если вы никогда не захотите использовать интеллектуальный HTTP (но имейте в виду, что он работает на Github и на любом другом разумном хостинге, и push не будет работать без него), вы можете экспортировать эту переменную среды в свой профиль оболочки.

Подробности об изменении на https://git.kernel.org/cgit/git/git.git/commit/?id=02572c2e3afcc200936260f48863447726212a7c.

person Jan Krüger    schedule 12.06.2013
comment
Тем временем я слышал об этом изменении, но ваше объяснение действительно помогает, спасибо! - person namnor; 13.06.2013

arrow_upward
0
arrow_downward

Недавно я столкнулся с той же проблемой при переносе моего репозитория Git в следующее облако. Я проверил содержимое репозитория и обнаружил, что там нет такой информации о файлах/ссылках.

Исследование, которое привело меня к этой теме: https://stackoverflow.com/questions/19698352/cant-clone-git-repos-via-http-info-refs-not-found

Выполнение предложенной команды git update-server-info в базовом каталоге репозитория создало отсутствующий файл, и ошибка 404 больше не появлялась. Таким образом, строка запроса здесь не проблема.

К сожалению, я получаю еще одну ошибку ("ошибка: нет поддержки блокировки DAV на..."), которая задокументирована здесь https://help.nextcloud.com/t/webdav-lock-on-file-doesnt-work/21451 (со ссылкой на github-issue для проекта Nextcloud).

К сожалению, на Nextcloud пока нет репозиториев Git через WebDAV.

person bug.spencor    schedule 13.05.2018

arrow_upward
0
arrow_downward

Теперь это может быть более надежным: git clone(man) из репозитория SHA256, созданного Git с помощью SHA-1. поскольку алгоритм хэширования по умолчанию по глупому протоколу HTTP неправильно настроил результирующий репозиторий, что было исправлено с помощью Git 2.32 (второй квартал 2021 г., 8 лет спустя).

См. коммит 00bc839 (11 мая 2021 г.) от Эрик Вонг (ele828).
(объединено Хунио C Хамано -- gitster -- в commit bdff041, 20 мая 2021 г.)

remote-curl: исправить клонирование в репозиториях sha256.

Подписано: Эрик Вонг
Подписано: brian m. Карлсон

Процесс удаленного https должен обновить свой собственный экземпляр the_repository' when it sees an HTTP(S) remote is using sha256. Without this, parse_oid_hex()fails to handle sha256 OIDs when it's eventually called byparse_fetch()`.

Протестировано с:

git clone https://yhbt.net/sha256test.git
GIT_SMART_HTTP=0 git clone https://yhbt.net/sha256test.git
(plain http:// also works)

Клонирование URL-адреса через git:// не требует изменений

person VonC    schedule 23.05.2021