он же на tk вроде был. выглядит жутко

конешно тортилка няшнее. всё привычно - пыщь-пыщь

проще её только веб-интерфейс )

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

Лоол, я знаю, что хуже выглядит, чем SourceTree 😂

SmartGit

Но так как он действительно Smart и умеет многое, чего из gui не умеет кажется больше почти никто — приходится его юзать

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

Без понятия, не пользуюсь сабмодулями и вам не советую

Но сабмодули распознаёт, кстати

Для решения этой проблемы вроде worktree сделали?

Бтв, монорепозитории — гораздо удобнее, такой проблемы нет как класса

Нет тут важно именно, что при git checkout iss53 сабмодуль переключится на одноименную ветку

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

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

Тут наверно проще либо руками переключать ветку репозитория, либо хранить где-то имя ветки и скрипт переключения сабмодуля на эту ветку. В обоих случаях нет большой нужны коммитить сабмодуль в репозитории, можно либо вынести рядом и обращаться через "../subrepo" либо заигнорить в репозитории. Кстати в скрипт можно будет добавить и выкачивание этого репозитория, если его нет.

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

Например, у вас может быть несколько игр на одном движке (например на cocos2d). Над каждым из проектов работает своя комманда, у каждого из проектов есть специфичные требования, не все из которых cocos2d может удовлетворять по умолчанию, по этому в проектах используется собственный модифицированный форк движка. Форк постоянно обновляют из основного репозитория.
- Держать движок в репозитории проекта или держать по форку на проект не целесообразно, т.к. это черезчур много лишней работы.
- Каждая из команд должна иметь возможность вносить правки в движок не влияя на работу других команд.
- Внутри одного проекта может существовать несколько веток, часть из которых должны иметь возможность использовать собственные ветки в движке или фиксированные коммиты на которые никак не повлияет работа в других ветках (релизные ветки). Другими словами, если часть команды обновляет движок для develop, то она не должна ничего поломать у другой части комманды, которая сейчас готовит версию к релизу.

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

А, да, вызов скрипта можно повесить на hook "post-checkout"

Правила чата: http://telegra.ph/git-05-15

как посмотреть подробные изменения в файле через консоль

git diff file_name

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