git submodules и detached HEAD

Сабмодули не должны самопроизвольно меняться. Коммит, на который указывает ветка, может меняться. Следовательно, в родительском репозитории надо привязываться именно к коммитам, хоть это и вызывает неудобства при использовании.

Что значит самопроизвольно и почему не должны? Для меня и для тех 100500 вопрошающих сабмодули - это лишь более удобный способ организации проекта, состоящего из нескольких репозиториев. Например репозиториев микросервисного проекта. Как работать с сабмодулями в состоянии detached HEAD? Любой новый коммит в таком сабмодуле не привязывается ни к одному бранчу и может легко потеряться. Общая рекомендация - никогда ничего не коммитить в состоянии detached HEAD, а тут такое непотребство по умолчанию.

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

Потому что кому надо те хотят ненужного и опасного.

Если бы они менялись, то дважды склонировав репозиторий можно было бы получить два разных результата. git это не средство управления кучей репозиториев, а система версионирования. Система версионирования, которая даёт невоспроизводимые результаты, не нужна. Тут либо использовать что-то другое, либо привыкнуть делать checkout.

это лишь более удобный способ организации проекта

Или картечница Гатлинга для октопуси.

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

Ну вот с обычным репозиторием всё именно так. Если его дважды, с некоторым промежутком времени, склонировать, можно получить два разных результата.

git это не средство управления кучей репозиториев, а система версионирования. Система версионирования, которая даёт невоспроизводимые результаты, не нужна.

Для этого существуют метки.

У тебя есть какое-то другое объяснение detached HEAD по умолчанию в сабмодулях?

Потому что кому надо те хотят ненужного и опасного.

Мысль не раскрыта. Что тут ненужного или опасного?

Или картечница Гатлинга для октопуси.

Переведи на русский

Git делали дураки, вот почему.

Использовать git submodules не как способ притянуть конкретный коммит, где конкретное значение коммита версионируется вместе с остальной репой. Хочешь помойку с отдельным версионированием — положи туда checkout без submodules, главное никому не рассказывай.

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

Это же можно сказать и о бранчах обычных репозиториев. Притянуть конкретный коммит может понадобиться при сборке и для этого придумали метки. А мне нужно заниматься разработкой и поэтому нужны конкретные бранчи, а не просто коммиты в состоянии detached HEAD. Расскажи, как мне делать новые коммиты в detached HEAD сабмодулях?

Хочешь помойку с отдельным версионированием — положи туда checkout без submodules, главное никому не рассказывай.

Что значит «положи туда checkout без submodules»?

Git делали дураки, вот почему.

Интересная теория, но я всё таки полагаю, что какая-то логика за всеми такими решениями стоит, просто никто из ораторов ещё не смог внятно её сформулировать.

Наверняка стоит. И наверняка дурацкая.

А мне нужно заниматься разработкой и поэтому нужны конкретные бранчи, а не просто коммиты в состоянии detached HEAD. Расскажи, как мне делать новые коммиты в detached HEAD сабмодулях?

Никак. Не делай этого. Делай коммиты в отдельных чекаутах, затем адвансь сабмодули.

Что значит «положи туда checkout без submodules»?

git checkout <url> <dumpster-of-a-project>/formerly-a-path-to-submodule

Никак. Не делай этого. Делай коммиты в отдельных чекаутах, затем адвансь сабмодули.

В смысле клонировать сабмодули отдельно и работать с ними там отдельно? Тогда зачем вообще нужны сабмодули?

git checkout <url> <dumpster-of-a-project>/formerly-a-path-to-submodule

Что это за странная и к тому же неработающая команда? Я знаю, что чекаут можно делать на бранч, метку, коммит, а тут почему-то url.

Ну вот с обычным репозиторием всё именно так.

Не всё. Если сделать git checkout на коммит, то результат будет всегда одинаковый. Если не привязывать коммиты основного репозитория к коммитам сабмодулей, то этого не будет.

Для этого существуют метки.

Метки тоже можно поменять, а хеш коммита нельзя.

У тебя есть какое-то другое объяснение detached HEAD по умолчанию в сабмодулях?

Нет.

Что это за странная и к тому же неработающая команда?

s/clone/checkout/

В смысле клонировать сабмодули отдельно и работать с ними там отдельно?

Да.

Тогда зачем вообще нужны сабмодули?

Как способ указатели на конкретный коммит, который чекаутить при сборке. Такой вот костыль.

Как способ указатели на конкретный коммит, который чекаутить при сборке. Такой вот костыль.

Какой-то странный костыль. В каком файле сидят эти указатели? Почему их нет в .gitmodules и как их вообще менять на произвольный (а не на последний) коммит?

Похоже thesis прав и это какой-то дурной дизайн.

Метки тоже можно поменять, а хеш коммита нельзя.

Всё можно менять, хотя и не всегда стоит, а иногда это не безопасно. Вот и метки обычно не меняют.

Если не привязывать коммиты основного репозитория к коммитам сабмодулей, то этого не будет.

В моём случае это и не надо. Я не devops и билды не собираю. Мне эта привязка нахрен не упала. Мно просто нужно одновременно работать с множеством репозиториев одновременно. Есть repo скрипт на Python от Google, но я предпочитаю стандартные решения.

О каких неудобствах и ожидаемом поведении идёт речь?

Всё можно менять, хотя и не всегда стоит, а иногда это не безопасно. Вот и метки обычно не меняют.

При смене коммита хеш тоже изменится (коллизию игнорируем).

но я предпочитаю стандартные решения.

Стандартное решение не будет разваливаться случайным образом. При этом никто не мешает пойти в сабмодуль и сделать там git checkout на ветку после клонирования родителя и работать дальше. По крайней мере, я не помню с этим проблем.

Или картечница Гатлинга для октопуси.

Переведи на русский

Пушка Гатлинга, Octocat.

В переводе: git submodules – надёжный способ отстрелить все ноги не только себе, но и всем вокруг.

При смене коммита хеш тоже изменится

Банальный rebase меняет хеши коммитов.

Стандартное решение не будет разваливаться случайным образом.

Именно.

При этом никто не мешает пойти в сабмодуль и сделать там git checkout на ветку после клонирования родителя и работать дальше. По крайней мере, я не помню с этим проблем.

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

Банальный rebase меняет хеши коммитов.

Он сам коммит меняет, так как коммит это не только данные, но ещё и метаданные (сообщение и список родителей, а смена родителей любые данные может поменять).

Тут легко запутаться.

Если их много, то не спорю.

Он сам коммит меняет, так как коммит это не только данные, но ещё и метаданные (сообщение и список родителей, а смена родителей любые данные может поменять).

Ещё коммитер и дата коммита. То есть ты можешь вабрать pick и скорее всего там изменится лишь время коммита, реже ещё и коммитер, если автор предыдущий - не ты.

git submodules – надёжный способ отстрелить все ноги не только себе, но и всем вокруг.

В нынешнем виде да, но почему ему не добавять функциональность для RnD? Не все же devops.

но почему ему не добавять функциональность для RnD?

Так есть же настройки (update, branch). Или и с ними что-то не так?

Так есть же настройки (update, branch). Или и с ними что-то не так?

Пробовал, не помогает. А ты сам попробуй.

Прав.

Поэтому мы переехали на монореп.