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

Линус, когда пилил Git, явно не планировал делать его решением подходящим для всех. Просто Linux-у для хранения исходников ядра запретили использовать на халяву платное решение (BitKeeper). Вот Линус и запилил Git на коленке, из кучи разных утилит и языков программирования. При этом он пилил не VCS, а систему управления базой данных VCS (чем по сути и является Git). Т.е. git сам по себе - это довольно низкоуровневая штука (что не удивительно, ведь Линус, как разработчик ядра, имеет хороший опыт создания низкоуровневых систем). Предполагалось, что поверх git-а будут создавать отдельные фронтенды, и несколько специализированных даже было создано. Но как то всё пошло не так, и git получил распространение в том виде, в каком он есть - с кучек низкоуровневых, не простых и опасных операций, с не очень адекватным для целей простого программиста CLI.

С другой стороны есть Mercurial, который изначально разрабатывался с идей об его удобном и простом использовании именно как VCS, с которой непосредственно будут работать пользователи без всяких дополнительных фронтендов. Поэтому у них и более адекватный и простой в изучении CLI.

http://nvie.com/posts/a-successful-git-branching-model/ можно и нужно применять хоть в гите, хоть в hg. Но hg не нужен, да. Пока не доказано обратное, ибо зачем плодить сущности.

согласен, это вопрос терминологии. Для меня ветки hg не узабельны, в том числе и из-за п.2

>2

Неиллюзорные проблемы мержа в свою репу я испытываю в hg. Дело касается реально больших изменений, когда в стороннем репе используются свои ветки. Поэтому мне это не удобно, да

Хорошо. Любой путь к листу в графе коммитов. А узел в графе коммитов у которого два потомка --- это branch point. Так лучше?

Я понимаю, что там где-то под капотом IDEA, возможно, и вызывает git-add, но сам я — нет, т.к. незачем. А коль понадобится раз в полгода закоммитить правки в файле через одну, ну, скомандую git commit --patch, делов-то. Ну то есть понятно, что диды с торвольцом завещали сначала добавлять правки в индекс, потом коммититься и всё такое, но с каких пор подумать своей головой стало ракетной наукой?

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