Я настраиваю тест-архитектуру. В этой системе виртуальная машина должна тестировать конкретную версию кода. Виртуальная машина полностью чистая и не имеет локальной (обновляемой) версии репо. Код размещается на локальном git-сервере, поверх ssh, с пользователем по имени git. Я полностью контролирую обе машины.

Простое решение:

git clone --no-checkout git@gitserver:reponame.git
git checkout 8e8fdea8f8367f4a179d2faddbaadba495d6bc12

Это работает, но делает слишком много: передает всю историю по сети, чего я хочу избежать, если это вообще возможно.

Из документации мне кажется, что git cloneможет быть выбран --branchвариант, но это не позволяет мне указывать конкретную ревизию. Если бы это было, это в сочетании с --depth 1будет работать для меня.

Альтернатива заключается в использовании git archive --remote. Я понимаю, что для безопасности это позволяет получить произвольные изменения, и в этом случае это не проблема, поэтому я запускаю

git config --global --bool --add uploadArchive.allowUnreachable 1

на сервере git как пользователь git.

Теперь на оболочке пользователя git я могу сделать

git archive --format tar.gz --remote reponame.git 8e8fdea8f8367f4a179d2faddbaadba495d6bc12

Кроме того, с моей виртуальной машины я могу запустить

git archive --format tar.gz --remote git@gitserver:reponame.git master

Однако не работает это:

git archive --format tar.gz --remote git@gitserver:reponame.git 8e8fdea8f8367f4a179d2faddbaadba495d6bc12

remote: fatal: no such ref: 8e8fdea8f8367f4a179d2faddbaadba495d6bc12
remote: git upload-archive: archiver died with error
fatal: sent error to the client: git upload-archive: archiver died with error

И да, я указываю на тот же репо, что ревизия определенно находится в репо, она просто не будет работать с номером ревизии. Одна вещь, которая может иметь место, - то, что, если команды выполняются по ssh, ~/.gitconfigфайл по умолчанию не читается, хотя я не мог найти никакой информации по этому вопросу.

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

Меня интересуют как общие замечания о том, как мне получить единственную ревизию на чистой машине, так и решение конкретной проблемы невозможности использования git-архива с ревизией.

---

РЕДАКТИРОВАТЬ: Торек дал мне несколько идей о версиях (я работаю на OSX, с пакетом git 1.8.5.2 и 2.0.1, установленным через brew), и я сделал небольшой скрипт-обертку, git-upload-archiveчтобы выяснить, что происходит. Скрипт оболочки:

/usr/local/bin/git --version > /tmp/version
tee /tmp/stdin | /usr/local/bin/git-upload-archive "$1" | tee /tmp/stdout

и вызов git-архива с --execвозможностью запуска этого скрипта.

Версия написана 2.0.1. Однако та же проблема сохраняется ... Локально я могу вызвать git-archive с параметром -remote и sha1, если uploadarchive.allowunreachableон установлен, удаленно не могу. Интересно, что запрос (в /tmp/stdin) одинаков в обоих случаях, ответ отличается. Насколько я вижу, это потому, что git-upload-archive не выбирает правильную конфигурацию, если запущен через ssh; это можно показать с помощью локальной конфигурации в репо, и в этом случае это работает (мое замечание в комментариях, что это не сработало, было потому, что я действительно брал /usr/bin/git-upload-archive; старая версия, которая не позволяет этот флаг конфигурации ).

Проблема может быть решена путем вызова /usr/local/bin/git upload-archiveвместо /usr/local/bin/git-upload-archive. Это может быть даже предоставлено в качестве аргумента git-archive: --exec='/usr/local/bin/git-upload-archive'не работает, --exec='/usr/local/bin/git upload-archive'работает.

Так что проблема работает сейчас. Мне все равно было бы интересно (с академической точки зрения), почему git-upload-archive не берет конфигурацию. Возможно, это ошибка, о которой следует сообщить в проект git.

Автор: Claude Источник Размещён: 12.11.2019 09:53