Обновление подмодулей до их последней версии без накопления истории обновлений

Обновление подмодулей с помощью submodule --remote приведет к тому, что HEAD подмодулей, а не хэш, записанный в обертывании git repo. Но похоже, что обертка git repo будет продолжать управлять хешем из них сама по себе, бесполезно вводить шум в свою собственную историю.

например. после submodule update --remote произойдет изменение, внесенное в проект упаковки, например:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   <module-name> (new commits)

Возможно, не включать хэши или информацию о хеше субмодулей в репозитории git, содержащие подмодули, такие, что submodule update не будет вводить необходимость в новых коммитах и ​​не будет отражена в истории проекта

Мотивационный сценарий:

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

ОТВЕТЫ

Ответ 1

Длинный ответ

Возможно, не включать хэши или информацию о хэше субмодулей

Нет, это вся точка подмодуля: записать в родительском репо фиксированный SHA1 (то есть gitlink, специальная запись в индексе).

В качестве удобства вы можете обновить содержимое подмодуля, чтобы он соответствовал удаленной ветке репозитория верхнего уровня подмодуля.
(git submodule update --remote)

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

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

Commit 9937e65 (Git 2.0, январь 2014) упоминает:

Прояснить, что не происходит никакого неявного плавания; --remote позволяет вам явно интегрировать ветвь вверх по течению в вашем текущем HEAD (точно так же, как работает "git pull" в подмодуле).
Единственным отличием от текущего "git pull" является расположение конфигурации и который используется для ветки вверх по течению, которая, как мы надеемся, теперь понятна.

зафиксировать 23d25e4 подробности:

Эта фиксация не изменяет логику обновлений после первоначального клонирования, которая будет продолжать создавать отдельные главы для обновлений режима проверки и интегрировать удаленные работы с локальной HEAD (отсоединенной или нет) в других режимах.

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

Например, если восходящий поток откатывает удаленную ветку или привязку с привязкой к более ранней версии, разработчик режима проверки хочет, чтобы их старая проверка подмодуля также была откатна, вместо того, чтобы получать не-op merge/rebase с помощью откат.

TL; DR

Вероятно, ничто в юниверсе git не может сделать репо автоматически указывать на самое последнее из подмодулей, а не на конкретный хэш хэша. Хотя submodule update --remote может использоваться как соглашение, чтобы игнорировать это отслеживание, история, описывающая обновления, всегда будет записываться в родительском репо.