Сделать репозиторий GIT менее мелким

Question

Я создаю мелкий клон для указанного тега:

git clone --branch v0.1.3 --depth 1 file:///c/usr/sites/smc .

После этого клонированное хранилище содержит только тег v0.1.3 (и связанные файлы). У него нет истории всех изменений до или после этого тега (как я понимаю - исправьте меня, если ошибаетесь.) Далее я хотел бы обновить клон, чтобы включить v0.1.4. Если я использую команду "git fetch --unshallow", то получаю полную историю, которая мне не нужна. Есть ли способ расширить мой клон, чтобы включить более новую историю от мастера (например, v0.1.4 и 0.1.5), но не более старую историю (например, 0.1.2)? (Я вижу опцию, называемую update-shallow, но не понимаю, что она делает или имеет ли она отношение.)

Целью этого является:

1) Сделайте начальную настройку репозитория на удаленном сервере быстрой и маленькой, не клонируя весь репозиторий. (Наше репо - это в основном двоичные файлы: DLL, EXE.)

2) Возможность обновления удаленного репо до более поздних версий (как указано в теге), но не до более ранних версий. Такое обновление будет передавать только часть хранилища, поэтому оно также должно быть быстрым.

ПРИМЕЧАНИЕ. Моя версия Git 1.9.2.msysgit.0 для Windows 7. Это включает в себя последние усовершенствования мелкого клонирования. Скорее всего, мы разместим основной репозиторий в Linux, но агенты, на которых мы развертываем, работают под управлением Windows. Намерение состоит в том, чтобы управлять проверками, используя кукольное предприятие.

ОБНОВЛЕНИЕ: Попробовал предложение VonC.

$ git fetch --update-shallow origin v0.1.4
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From file:///c/usr/sites/smc
 * tag               v0.1.4     -> FETCH_HEAD

paul.chernoch@USB-XXXXXXXXX /c/usr/sites/smc-clone3 ((v0.1.3))
$ git describe
v0.1.3

paul.chernoch@USB-XXXXXXXXX /c/usr/sites/smc-clone3 ((v0.1.3))
$ git tag --list
v0.1.3

Хотя команда, похоже, что-то делает, я не вижу тега v0.1.4 в моем целевом репо. Однако, если я использую опцию --tags, я получу все теги, но также и всю историю! Кроме того, я не понимаю обозначение "FETCH_HEAD" в выходных данных команды git fetch.

ОБНОВЛЕНИЕ: Дальнейшие исследования показывают, что этот вопрос SO преследует аналогичную цель: сделать небольшой клон на конкретный тег

Answer 1

Кажется, у меня был подобный вопрос к этому и нашел это впоследствии. Хитрость заключалась в том, чтобы указать полный refspec в конце и глубину в команде fetch. refs/tags/v0.1.3:refs/tags/v0.1.3 или тег v0.1.3 для краткости

Git мелкий выбор нового тега

git fetch --depth 1 origin tag v0.1.4

Answer 2

Эта опция обновляет .git/shallow и принимаем такие ссылки.

Но это будет лучше работать с Git 2.27 (второй квартал 2020 г.), который устраняет несогласованность в ядре после загрузки в неглубокий репозиторий, который нарушил код для записи графика фиксации.

Это также повлияет git push.

См. Commit 37b9dca (23 апреля 2020 г.) и commit 8a8da49 (24 апреля 2020 г.) Тейлор Блау (ttaylorr).
^{(Слияние Junio ​​C Hamano -gitster- в коммите 2b4ff3d, 01 мая 2020 г.)}

shallow.c: use '{commit,rollback}_shallow_file'

^{Помощник: Джонатан Тан
Помощник: Джунио С. Хамано
Подпись: Тейлор Блау
Автор отзыва: Джонатан Тан}

В bd0b42aed3 ("fetch-pack: не использовать мелкую блокировку без надобности ", 2019-01-10, Git v2.21.0-rc0 - слияние указано в пакете №4), автор отметил, что"is_repository_shallow'производит видимые побочные эффекты, устанавливая'is_shallow' а также 'shallow_stat'.

Это проблема, например, при загрузке с помощью '--update-shallow'в мелком репозитории с'fetch.writeCommitGraph'включен, так как обновление до'.git/shallow'заставит Git подумать, что репозиторий не мелкий, когда он есть, тем самым обойдя проверку совместимости с графом фиксации.

Это вызывает проблемы в неглубоких репозиториях с хотя бы мелкими ссылками, имеющими хотя бы одного предка (поскольку у клиента не будет этих объектов, и поэтому он не может принять закрытие достижимости вместо коммитов при написании commit-graph).

Решите эту проблему, введя тонкие обертки поверх 'commit_lock_file' а также 'rollback_lock_file'специально для использования при удерживании замка'.git/shallow'.
Эти обертки (соответственно называемые 'commit_shallow_file' а также 'rollback_shallow_file') вызывают их соответствующие функции в' lockfile.h', но дополнительно сбросить проверки действительности, используемые неглубоким оборудованием.

Замените каждый экземпляр "commit_lock_file' а также 'rollback_lock_file' с 'commit_shallow_file' а также 'rollback_shallow_file'когда удерживаемый замок превышает'.git/shallow' файл.

Как результат, 'prune_shallow'теперь можно вызвать только один раз (поскольку'check_shallow_file_for_update'умрет после звонка'reset_repository_shallow'). Но это нормально, потому что мы звоним только "prune_shallow'не более одного раза за процесс.

---

Предупреждение, до Git 2.28 (3 квартал 2020 г.) "fetch.writeCommitGraph"был включен, когда запрашивается"feature.experimental", но в его нынешней форме это было слишком рискованно даже для смелых людей.

Конфигурация исключена, по крайней мере, на данный момент, из "экспериментального" набора функций.

См. Коммит b5651a2 (06 июля 2020 г.) Джонатана Нидера (artagnon).
^{(Слияние Junio ​​C Hamano -gitster- в коммите 9850823, 09 июл 2020)}

experimental: по умолчанию fetch.writeCommitGraph=false

^{Автор отчета: Джей Конрод.
Помощник: Тейлор Блау.
Подпись: Джонатан Нидер.}

В fetch.writeCommitGraph Функция заставляет выборки записывать файл графика фиксации для недавно загруженного пакета при выборке.

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

Чтобы подготовиться к этому будущему, он включен по умолчанию для пользователей, которые установили feature.experimental=true, чтобы испытать такие будущие значения по умолчанию.

Увы, для --unshallow извлекается из неглубокого клона, он сталкивается с загвоздкой: к тому времени, когда Git извлекает новые объекты и пишет граф фиксации, он выполнил обход изменений и r->parsed_objectsсодержит информацию о неглубокой границе до выборки.

Код записи графа фиксации осторожен, чтобы избежать записи файла графа фиксации в неглубоких репозиториях, но новое состояние не является мелким, и в результате с этого момента команды, такие как "git log", используют только что написанный граф фиксации файл, представляющий вымышленную историю со старой неглубокой границей.

Мы могли бы исправить это, сделав код записи графа фиксации более осторожным, чтобы избежать написания графа фиксации, который мог бы использовать любые графты или неглубокое состояние, но возможно, что есть другие части измененного состояния, на которые может полагаться код записи графа фиксации на.

Поэтому отключите его в конфигурации feature.experimental.

Разработчики Google работали в этой конфигурации (установив fetch.writeCommitGraph=false в конфигурации системы), чтобы обойти эту ошибку, поскольку она была обнаружена в апреле.

Как только исправление появится, мы включим fetch.writeCommitGraph=true еще раз, чтобы протестировать его на раннем этапе, прежде чем распространять на более широкую аудиторию.

Другими словами:

• этот патч влияет только на поведение с feature.experimental=true
• он заставляет feature.experimental соответствовать конфигурации, которую Google использовал в течение последних нескольких месяцев, а это означает, что пользователи будут лучше протестированы, чем без нее.
• это должно улучшить тестирование других функций, охраняемых feature.experimental, сделав feature.experimental более безопасным в использовании

---

Кроме того, все еще с Git 2.28 (третий квартал 2020 г.), когда "fetch.writeCommitGraph"конфигурация установлена ​​в мелком репозитории, и выборка перемещает неглубокую границу, мы выписали сломанные файлы графика фиксации, которые не соответствуют действительности, что было исправлено.

См. Коммит ce16364 (8 июля 2020 г.) Тейлор Блау (ttaylorr).
^{(Слияние Junio ​​C Hamano -gitster- в коммите 24ecfdf, 09 июл 2020)}

commit.c: не настаивайте на замене родителей, когда не освящаете

^{Помощник: Деррик Столи.
Помощник: Джонатан Нидер.
Докладчик: Джей Конрод. Автор обзора
: Джонатан Нидер.
Подписано: Тейлор Блау.}

Поскольку 37b9dcabfc ( shallow.c: use '{commit,rollback}_shallow_file', 2020-04-22), Git знает, как сбросить проверки достоверности статистики для $GIT_DIR/shallow файл, позволяя ему переключаться между неглубоким и неглубоким состоянием в одном процессе (например, в случае "git fetch --unshallow").

Однако когда $GIT_DIR/shallow изменений, Git не изменяет и не удаляет какие-либо графты (или замененные родители) в памяти.

Это появляется в "git fetch --unshallow" с fetch.writeCommitGraph, установленным в true. Обычно в мелком репозитории (и до 37b9dcabfc, даже в этом случае),commit_graph_compatible()вернет false, указывая, что репозиторий не должен использоваться для записи графиков фиксации (поскольку файлы графов фиксации не могут представлять мелкую историю). Но, начиная с 37b9dcabfc, в операции --unshallow эта проверка выполняется успешно.

Таким образом, даже несмотря на то, что репозиторий больше не является мелким (то есть у нас есть все объекты), внутреннее представление этих объектов по-прежнему имеет измененных родителей на мелких границах.

Когда запись в граф фиксации продолжается, мы используем неверное происхождение, что приводит к неверным результатам.

Пользователь может обойти это двумя способами: либо (1) установить 'fetch.writeCommitGraph' в 'false', либо (2) удалить график фиксации после отмены разрешения.

Один из способов исправить это - полностью сбросить пул проанализированных объектов (очистить кеш и, таким образом, предотвратить изменение родительских объектов последующими чтениями) после отмены разрешения. Это может вызвать проблему, если у вызывающих абонентов будет устаревшая ссылка на старый пул, поэтому в этом патче реализован другой подход. Вместо этого прикрепите к пулу новый бит ",substituted_parent', который указывает, хранил ли когда-либо репозиторий фиксацию, родители которой были изменены (т.е. неглубокая граница до отмены разрешения).

Этот бит должен быть закрепленным, потому что все чтения после изменения родительских коммитов ненадежны при отмене разрешения. Изменить регистрацию 'commit_graph_compatible', чтобы учесть этот бит, и правильно избегать генерации графиков фиксации в этом случае, тем самым решив ошибку.