Здравствуйте, Bluebarry, Вы писали:

B>Хорошо, а если я для репозитория RepoA сделаю так:
B>

B>git remote add rem ../RepoB
B>git fetch rem

B>git remote rm rem
B>git remote add rem ../RepoC
B>git fetch rem
B>

B>(RepoB и RepoC - это клоны RepoA, но продвинувшиеся вперед)

B>Тогда в RepoA появится новая ветка rem/master c двумя головами. Как понять, что у нее две головы? Git log показывает только последнюю голову.

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

B>В меркуриале есть hg heads. А если ли аналог в Git?

К сожалению, с меркуриалом я незнаком, поэтому не знаю, что делает эта команда. Если показывает список всех голов, в том числе "висящих" (на которые нет ни тегов, ни веток), то в гите такого, насколько я знаю, нет. Все висящие коммиты для гита — мусор, который рано или поздно будет удалён garbage collector'ом.

B>Кроме того, TortoiseHG показывает всю историю, поэтому таких проблем не возникает.

Если бы Git и HG были одинаковы во всех мелочах, то не было бы смысла развивать оба. У каждого из них своя концепция, в рамках которой каждый и двигается вперёд. Функционально они практически идентичны (насколько я слышал), т.е. всё, что можно сделать в одном, можно сделать и в другом — пусть порой менее удобно и бо́льшим числом команд. А юзабилити у них, разумеется, нацелено в первую очередь на свой сценарий, и задачи, в него не укладывающиеся, неизбежно пострадают. В гите основной сценарий — не вытягивание веток из рандомных мест, а длительная работа с несколькими постоянными репозиториями. Если у каждого есть своё имя, они нормально сосуществуют и ни малейшим образом друг другу не мешают. На это нацелено и автосоздание origin при клонировании, и автосоздание локальной ветки при чекауте удалённой, и связывание локальных веток с удалёнными при пуше/пулле…