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

CF>>Веток с двумя головами не бывает. rem/master станет указывать на master из второго репа, первый при этом затеряется.
CF>> Все висящие коммиты для гита — мусор, который рано или поздно будет удалён garbage collector'ом.

B>Это плохо вяжется с радостными лозунгами, что в Гите невозможно ничего потерять.
B>Например, из Pro Git:
B>

As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.

B>Так все таки, насколько легко или трудно потерять коммиты при работе с гитом?
B>По моему опыту, в Меркуриале потерять закоммиченные изменения практически невозможно.

Боюсь, тут легко начать спорить о том, что такое "легко", а что такое "очень трудно". Просто надо учитывать, в каком контексте это всё рассказывается в Pro Git.
Конечно, если есть желание, то потерять коммит очень легко — как уже говорил, всего лишь сделать commit --amend. Старый коммит потерян, куда уж легче. Но, во-первых, если времени прошло немного, его ещё можно восстановить, глянув хэш через fsck или reflog и навесив ветку/тег. Во-вторых, если проект уже был запушен куда-то, то этот старый коммит сохранится там, пока не перепушишь новую версию (причём так просто ещё и не запушишь, потребуется задать флаг -f для форсированного перезатирания удалённой ветки, что само по себе крайне не рекомендуется). Речь о том, что если не вызывать явно деструктивных команд, данные не потеряешь. Напоролся на жуткое слияние, всё запортил, наворотил нерабочих коммитов — не проблема, всё в репозитории сохранилось, просто откатываешься назад. В процессе ребейза что-то пошло не так — прервал ребейз, всё автоматически вернулось в исходное состояние. В таком вот духе.
Даже в описанном сценарии с вытаскиванием коммитов из репозиториев по прямым путям коммит-то никуда не теряется: в исходном репозитории он остаётся. Это, скорее, не потеря, а "неполучение". Неприятно, согласен, но не критично.

B>Опишу свой workflow для отдельного проекта:
B> <skipped/>
B>Сейчас вот разбираюсь с гитом, и думаю, не перейти ли мне на него? И удобно ли использовать гит для текущего workflow? Или, может, адаптировать workflow? Пока что, мне кажется, что у меня будут постоянно теряться коммиты.

Сходу затруднительно решить, как в таком случае удобнее поступать. Если бы я с такой проблемой столкнулся, я бы для начала зафиксировал букву флэшки — пусть даже они будут разные на разных компах — и провесил remote на флэшку уже по этой букве. Как вариант: сделать в основную файловую систему симлинку на флэшку по её гуиду, тогда не будет зависимости от буквы диска. По возможности, вообще стараюсь унифицировать рабочее окружение на разных компах. Можно subst'ом содать виртуальный диск с одной и той же буквой на всех компах, на котором будет уже одинаковая структура каталогов/репозиториев, а на флэшке, соответственно, один remote на этот виртуальный диск. Можно и без унифицирования обойтись, создав на флэшке десяток удалёнок с уникальными именами для каждого компа, но придётся постоянно вспоминать названия.
Если не хочется создавать remote-имена, можно продолжить работать по путям, сделав алиас, который будет вызывать fetch и автоматически провешивать ветку или тег на FETCH_HEAD (только надо либо гарантированно эту ветку разруливать и удалять перед следующим фетчем либо продумать схему с уникальными именами этих временных веток). Можно попробовать копнуть в направление бандлов, может быть, ими окажется удобнее синхронизировать (тут я, к сожалению, плаваю, сам с ними почти не работал).

Вообще, многое зависит от целей. Чего хочется достичь переходом с hg на git? Если только из-за моды, то смысла нет. Насколько я слышал отзывы меркуриаловцев о гите, всякие подобные мелочи будут постоянно вылезать и раздражать.