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

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

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

Ну, из отдельного репозитория крайне неудобно, ибо каждый – CMake-подпроект, который линкуется с, по крайней мере, некоторыми, другими, так что это было бы крайне неудобно в разработке.

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

Что-то не звучит удобнее чем сделать один раз чекаут руками :)
Ну дело ваше

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

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

Только не один раз, а для каждого модуля...

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

Собственно, foreach тоже не самое элегантное решение как по мне, но да, это тоже вариант решения

git clone --recursive && git submodule update --init --recursive

всё остальное  про ветки - это уже неопределённые детали, которые, в общем случае, невозможно восстановить

git clone --recursive && git submodule update --init --recursive

а в частных случаях - скриптуется как надо

попытка запуска git rebase -i --committer-date-is-author-date стало вдруг приводить к
fatal: cannot combine am options with either interactive or merge options
кто сталкивался?

проблема именно из-за --committer-date-is-author-date при чем раньше все ок было. обновил гит с 2.18 на 2.22

Этот параметр passed to 'git am'

ну я чет не догоняю шо делать теперь

то есть он видит этот параметр, понимает, что надо использовать am, а am не совместим с interactive. так чтоль?

читать release notes )

я читал)

не нашел там именно про это

бле, нашел в доке

поведай