Git як ртутний клієнт? Чому немає git-hg?

Це питання турбує мене якийсь час. Я зробив домашнє завдання і перевірив stackoverflow і знайшов принаймні ці дві теми щодо свого запитання: Git для Mercurial, наприклад git-svn та Git, сумісність зі сховищем Mercurial

Я вирішив цю проблему серйозно погуглити, але поки що не везло. Я також прочитав книгу Git Internals та Mercurial Definitive Behind the Scenes, щоб спробувати зрозуміти це. Я все ще трохи спантеличений, чому мені не вдалося знайти будь-який відповідний тип інструменту git-hg.

З моєї точки зору, git-svn - одна з головних особливостей, чому я вирішив використовувати git над mercurial також на роботі. Це дозволяє мені використовувати робочий процес, який мені подобається, і нікому іншому не потрібно турбуватися, якщо їм все одно. Я просто не бачу сенсу використовувати проміжне hg-репо для перетворення вперед-назад, як пропонується в одному з ланцюжків.

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

Отже, справжнє запитання, чи існує якась реальна причина, чому git-hg не існує (або, принаймні, дуже важко знайти)? Чи існує якась ворожість користувачів git (та розробників) до їхніх колег hg, що спричинило відсутність інструменту git-hg? Чи планує хтось із вас розробити щось подібне і вийти з ним на публіку? Я міг би зголоситися (хоча і з дуже слабкими C-навичками) взяти участь, щоб це зробити. Я просто не маю повних знань, щоб запустити це сам.

Чи може це бути інструментом назавжди припинити всі війни DVCS?

hg-git та презентація автора на Pycon, що пояснює його думку щодо ситуації. не впевнений, чи стикалися ви з ними під час гуглиння, але вони відповідали на мої запитання.

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

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

Набір сценаріїв для перевірки та відстеження маркетингового [sic] проекту.

Здається, це не працює двонаправлено (див. Трекер випусків ).

Для реалізації цього є ще один проект: 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, bazaar і навіть 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

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

Не пропустіть коментарів і там.

Хтось уже згадував два git-remote-hg, але ось новий:

Підтримка моста в git для ртутного та базару

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

У ньому є великі тести, щоб перевірити, що результат точно такий же, як hg-git, тому він повинен працювати принаймні так само добре.

Існує новий проект, який реалізує саме це:

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

Це робить двосторонню річ гарно інтегрованою.

Я думаю, що насправді просто немає особливого стимулу для його створення. Ніхто не буде жахливо покалічений, коли доведеться використовувати одне над іншим; вони обидва DVCS. Звичайно, кожен, мабуть, має свої уподобання, але вони, як правило, просто всмоктують це і використовують інше, якщо потрібно. Я припускаю, що hg-git з’явився, тому що git дуже широко використовується, тоді як hg прийнято набагато менше проектів.

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

Ви, мабуть, маєте рацію, що це було б корисно мати, хоча, припускаючи, що одне з них не повільно перемагає іншого (я вважаю, git насправді має набагато більшу базу користувачів).

Ви також маєте рацію, що немає великих технічних перешкод - hg-git є двонаправленим, тому чітко можна нанести інформацію між ними.