Git как ртутный клиент? Почему нет мерзавца?

Question

Это вопрос, который беспокоит меня некоторое время. Я сделал свою домашнюю работу и проверил stackoverflow и нашел по крайней мере эти две темы о моем вопросе: Git для Mercurial типа git-svn и Совместимость Git с репозиторием Mercurial

Я решил серьезно заняться поиском, но пока безуспешно. Я также прочитал книгу Git Internals и Mercurial Definition за кулисами , чтобы попытаться выяснить это. Я все еще немного озадачен, почему я не смог найти подходящий инструмент типа git-hg.

С моей точки зрения, git-svn - одна из основных функций, поэтому я решил использовать git вместо mercurial и на работе. Это позволяет мне использовать рабочий процесс, который мне нравится, и никто больше не должен беспокоиться, если им все равно. Я просто не вижу смысла в использовании промежуточного репозитория hg для конвертации назад и вперед, как это предлагается в одной из цепочек.

Так или иначе, из того, что я читал, hg и git кажутся очень похожими в концептуальном дизайне. Под капотом есть различия , но ни одно из них не должно препятствовать созданию git-клиента для hg. Как мне кажется, удаленное отслеживание веток и слияние осьминогов делают git еще более мощным, чем hg.

Итак, реальный вопрос, есть ли реальная причина, по которой git-hg не существует (или, по крайней мере, его очень трудно найти)? Есть ли некоторая враждебность со стороны пользователей git (и разработчиков) по отношению к их коллегам по hg, что вызвало отсутствие инструмента git-hg? Есть ли у кого-нибудь из вас планы по разработке чего-то подобного, и обнародовать это? Я мог бы добровольно (хотя и с очень слабыми C-навыками) участвовать, чтобы сделать это. Я просто не обладаю полным знанием, чтобы начать это сам.

Может ли это быть инструментом для окончательного прекращения всех войн DVCS?

Answer 1

Я не пробовал это, но, похоже, есть проект git-hg . Проект описывает себя на странице и README как:

Утилита git-hg для проверки и отслеживание ртутного репо.

Набор скрипты для проверки и отслеживания проект [sic].

Хотя, похоже, он не работает в двух направлениях (см. средство отслеживания проблем ).

Answer 2

hg-git и авторская Pycon презентация , объясняющая его взгляд на ситуацию. Не уверен, что вы сталкивались с этим во время поиска в Google, но они ответили на мои вопросы.

Answer 3

Есть еще один проект для реализации этого: git-remote-hg. На самом деле два из них, родной (см. https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg), и другой, основанный на hg-git (см. https://github.com/rfk/git-remote-hg).). Первый намного быстрее, чем второй, но все еще неполон и находится в стадии разработки. *

На самом деле для других систем существуют удаленные помощники git (как называются эти инструменты), которые уже существуют или находятся в стадии разработки; это включает в себя поддержку Subversion, CVS, базара и даже MediaWiki.

Клонирование репозитория Mercurial с помощью git просто выполняется следующим образом:

git clone hg::https://hg.example.com/some-mercurial-repo

ОБНОВЛЕНИЕ: К настоящему времени существует третий, тоже "родной", а именно тот, который Фелипе упоминает в своем ответе здесь. Похоже, что скоро он станет частью каталога git 'contrib': https://github.com/felipec/git-remote-hg Он работает, не требуя патчей для git, хотя некоторые патчи для git (сейчас на рассмотрении) могут применяться для улучшения общего пользовательского опыта.

ОБНОВЛЕНИЕ 2: И теперь есть еще один претендент, который находится в стадии довольно активной разработки и основан на коде Фелипе: https://github.com/buchuki/gitifyhg - он пока работает довольно хорошо для меня, но все еще есть некоторые грубые пятна.

ОБНОВЛЕНИЕ 3: gitifyhg и git-remote-hg Фелипе в настоящее время активно не поддерживаются. В настоящее время я сделал форму кода Фелипе с некоторыми исправлениями, включая некоторые, чтобы он работал с последними версиями Mercurial. Вы можете получить его от https://github.com/fingolfin/git-remote-hg. Наконец, есть еще один недавний претендент, git-cinnabar, использующий совершенно другой подход внутри (хотя, если вам это не важно, его использование более или менее совпадает с для других реализаций git-remote-hg). Я еще не пробовал сам, но вы можете найти его в https://github.com/glandium/git-cinnabar

Answer 4

hg-git, по-видимому, может использоваться для локальной работы с git с удаленным ртутным репо: http://traviscline.com/blog/2010/04/27/using-hg-git-to-work-in-git-and-push-to-hg/

Не пропустите комментарии там тоже.

Answer 5

Кто-то уже упоминал о двух git-remote-hg, но вот новый:

Поддержка моста в Git для Mercurial и Bazaar

Он имеет больше функций и должен работать более надежно, чем msysgit, но самое главное; вам не нужны никакие зависимости или пользовательская сборка git. Просто скопируйте в $ PATH , и все.

Он имеет обширные тесты, чтобы проверить, что вывод точно такой же, как и у hg-git, поэтому он должен работать как минимум.

Answer 6

Существует новый проект, который выполняет именно это:

• https://github.com/abourget/git-hg-again

Это делает двустороннюю вещь хорошо интегрированной.

Answer 7

Я думаю, что на самом деле не так уж много стимулов для его создания. Никто не будет ужасно искалечен, если использовать один поверх другого; они оба DVCS. Конечно, у каждого, вероятно, есть свои предпочтения, но они, как правило, просто смирятся с этим и будут использовать другого, если придется. Я предполагаю, что hg-git появился, потому что git очень широко используется, в то время как намного меньше проектов приняли hg.

В отличие от этого, если в проекте используется svn или cvs, любой, кто имел вкус к DVCS, будет страдать - и он захочет эту утилиту git-svn / hg-svn. Существует множество проектов, в которых все еще используется cvs / svn, поэтому большой спрос.

Вы, вероятно, правы, что было бы полезно иметь это, хотя, если предположить, что одно из двух не будет медленно выигрывать у другого (я думаю, что git действительно имеет гораздо большую базу пользователей).

Вы также правы, что нет больших технических препятствий - hg-git является двунаправленным, поэтому ясно, что можно сопоставить информацию между ними.