git submodule ветки

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

Субмодули - вообще какая мутная хрень, непонятно зачем придуманная. Ну, использует у тебя проект какой-то другой проект - ну и пусть лежат отдельно, всё равно их по отдельности пилить. Управление зависимостями там всё равно никакое - судя по тому, что один хрен всё приходится в голове держать.

использует у тебя проект какой-то другой проект

ну сам же себе ответил — проекты разные. шош ты сабмодули в основном проекте то правишь?

Сабмодули реально неприятные и лучше их не использовать.
Я пробовал запилить проект с шестью сабмодулями, по сути это были зависимости без которых нельзя, но которые потом хотелось переиспользовать. И всё было хорошо и удобно пол года, ну может пару раз кто-то забывал ‘’recursive’’ указать при клонировании. А потом всё взорвалось нафиг.

Сабмодули реально неприятные и лучше их не использовать ... потом всё взорвалось нафиг

я такие же прохладные истории про goto слышу.

ни чего не понял.

есть в основном проекте 50 релизных веток (включая мастера): master, brahchName1, brahchName2, brahchName3, … brahchName49. Все ветки - РЕЛИЗНЫЕ!!!

есть сабмодуль s1. У этого модуля 20 веток: s1_1, s1_2, s1_3, …s1_20. Все 20 веток РЕЛИЗНЫЕ и рабочие, и используются в разных проектах и в разных ветках. Это исходные данные. Кто с этим не согласен - проходим мимо (я тоже с этим в корне не согласен, но не я это придумал).

Мне дают задачу: Поправить основной проект в ветке brahchName47. Это релизная ветка. Дают ссылку на репазиторий и имя ветки. Я клонирую себе проект со всеми субмодулями, переключаю проект на ветку brahchName47. Захожу в папку субмодуля s1 и смотрю на какой он ветке. s1 в состоянии деаттач. На какую мне ветку переключить s1? Как узнать?

я конечно могу пойти по всяким инстанция и искать авторов кода, которые уже давно кто в др. стране, кто умер…. и в итоге я таки найду нужную ветку и переключусь на неё. Но, как сделать связку project:brahchName47<->s1:s1_3 не на стикере у монитора, а средствами git, чтоб в будущем переключивщись на brahchName47 субмодуль тоже переключался на s1_3 (пусть даже дополнительной командой типа git sub update, но чтобы гит сам знал куда ему переключиться и до чего обновиться)?

Сабмодули так работают и не могут иначе. Они хранят ссылку на коммит, а не на ветку. Если бы можно было хранить ветку или тег, то содержимое сабмодуля менялось бы во времени.

После checkout оно в состоянии готовом для родительского проекта. Состояние для разработки сабмодуля это отдельная тема. Если надо найти ветку, то какой-нибудь git branch --contains HEAD в руки.

Все 20 веток РЕЛИЗНЫЕ и рабочие, и используются в разных проектах и в разных ветках

бардак на бардаке бардаком погоняет.

Что только народ не придумает, лишь бы не использовать Subversion!

«Сабмодули так работают и не могут иначе. Они хранят ссылку на коммит, а не на ветку. Если бы можно было хранить ветку или тег, то содержимое сабмодуля менялось бы во времени.» - спс. Пока что придумал в родительском проекте держать readme, и в нем писать «стикер» - что, где, от куда и какую ветку субмодуля.

«Это содержимое сабмодуля менялось бы во времени.» - так и нужно.

«Это содержимое сабмодуля менялось бы во времени.» - так и нужно.

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

С вложенными репозиториями вообще нет никаких проблем. Выдумывать просто фигни не нужно и всё. У тебя всегда есть конкретная версия корня. И соответствующие ему конкретные версии вложеных реп. Всё просто и круто.

Именование веток – это вообще отпад. Фишка в том, что git submodules не решают проблемы дерьмовой организации. Они вообще тут не при чём.

«У тебя всегда есть конкретная версия корня. И соответствующие ему конкретные версии вложеных реп» об этом я и спрашиваю. как это сделать. Есть конкретная версия корня - project:brahchName47. Этому корню должен соответствовать конкретная версия вложенного репа - s1:s1_3. Как сделать эту связку?

«здесь нужны не сабмодули и просто независимые репозитории» - а какая разница - сабмодули или независимые репозитории?

«какой-то скрипт, который делает …» - да, скорее всего лучшее будет вместо редми скрипт написать. Тут неважно субмодули или отдельный репы. В обоих случаях скрипт выполнит клонирование/переключение на нужные ветки/обновление всех репов/субмодулей….

А в чем страдания? Узнать потом имя ветки по хешу?

Можно так: git branch --contains <commit>

Есть конкретная версия корня - project:brahchName47. Этому корню должен соответствовать конкретная версия вложенного репа - s1:s1_3. Как сделать эту связку?

Фиксацией, как обычно. Гит, мать его, коммит.

А в чем страдания? Узнать потом имя ветки по хешу?

Коммит может принадлежать нескольким веткам.

Ну-ка, изобрази? )

git co -b feature/x

Повторить до достижения необходимого уровня просветления. Потом сделай пару коммитов. Обнови референс корня фиксацией. Сделай squash ветки feature/x и залей её в develop или мастер. Лол – ветка, это всего лишь ничего не значащая фигня для удобства.

«Фиксацией, как обычно. Гит, мать его, коммит.» - читал мой первый пост? Не делает комит эту связку.