Git en tant que client Mercurial? Pourquoi pas de git-hg?
C'est une question qui me dérange depuis un moment. J'ai fait mes devoirs et vérifié stackoverflow et trouvé au moins ces deux sujets sur ma question: Git pour Mercurial comme git-svn et interopérabilité Git avec un référentiel Mercurial
J'ai fait de sérieuses recherches sur Google pour résoudre ce problème, mais jusqu'à présent sans succès. J'ai également lu le livre Git Internals , et le Mercurial Definitive Behind the Scenes pour essayer de comprendre cela. Je suis toujours un peu perplexe de ne pas avoir trouvé de type d'outil git-hg approprié.
De mon point de vue, git-svn est l'une des principales fonctionnalités, c'est pourquoi j'ai choisi d'utiliser git sur Mercurial également au travail. Cela me permet d'utiliser un flux de travail que j'aime, et personne d'autre n'a à s'en soucier, s'il s'en fiche. Je ne vois tout simplement pas l'intérêt d'utiliser le référentiel hg intermédiaire pour convertir dans les deux sens, comme suggéré dans l'une des chaînes.
De toute façon, d'après ce que j'ai lu, hg et git semblent très similaires dans la conception. Il y a différences sous le capot , mais aucun de ceux-ci ne devrait empêcher la création d'un client git pour hg. Comme il me semble, les branches de suivi à distance et les fusions de poulpes rendent git encore plus puissant que le hg.
Donc, la vraie question, y a-t-il une vraie raison pour laquelle git-hg n'existe pas (ou du moins est très difficile à trouver)? Y a-t-il une certaine animosité des utilisateurs (et des développeurs) de git envers leurs homologues hg qui a causé le manque de l'outil git-hg? Avez-vous l'intention de développer quelque chose comme ça et de le rendre public? Je pourrais me porter volontaire (bien qu'avec des compétences C très faibles) pour y participer. Je ne possède tout simplement pas toutes les connaissances nécessaires pour démarrer cela moi-même.
Serait-ce l'outil pour mettre fin définitivement à toutes les guerres DVCS?
hg-git et l'auteur présentation Pycon expliquant son point de vue sur la situation. Je ne sais pas si vous les avez rencontrés pendant la recherche sur Google, mais ils ont répondu à mes questions.
Je n'ai pas essayé cela, mais il semble y avoir un projet git-hg . Le projet se décrit sur la page et le README comme:
Un utilitaire git-hg pour vérifier et suivre un dépôt Mercurial.
Un ensemble de scripts pour extraire et suivre un projet mercrial [sic].
Cela ne semble cependant pas fonctionner dans les deux sens (voir issue tracker ).
Il existe un autre projet pour le réaliser: git-remote-hg. En fait, deux d'entre eux, un natif (voir https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg ) et un autre basé sur hg-git ( voir https://github.com/rfk/git-remote-hg ). Le premier est beaucoup plus rapide que le second, mais encore incomplet et en cours de développement.
Il existe en fait des assistants distants git (comme ces outils sont appelés) pour d'autres systèmes, déjà existants ou en cours de développement; cela inclut la prise en charge de Subversion, CVS, Bazaar et même MediaWiki.
Le clonage d'un dépôt Mercurial via git se fait alors simplement comme ceci:
git clone hg::https://hg.example.com/some-Mercurial-repo
MISE À JOUR: Il y en a maintenant un troisième, également "natif", à savoir celui de Felipe qu'il mentionne dans sa réponse ici. Celui-ci semble bientôt faire partie du répertoire git 'contrib': https://github.com/felipec/git-remote-hg Il fonctionne sans nécessiter de correctifs pour git lui-même, bien que certains des correctifs pour git (en cours d'examen maintenant) peuvent être appliqués pour améliorer l'expérience globale de l'utilisateur.
MISE À JOUR 2: Et maintenant il y a encore un autre concurrent, celui-ci étant en cours de développement assez actif, et basé sur le code de Felipe: https://github.com/buchuki/gitifyhg - cela fonctionne très bien pour moi jusqu'à présent, mais il y a encore des moments difficiles.
MISE À JOUR 3: gitifyhg et git-remote-hg de Felipe ne sont actuellement pas activement maintenus. Pour l'instant, j'ai fait une forme de code de Felipe avec quelques correctifs, dont certains pour le faire fonctionner avec les versions récentes de Mercurial. Vous pouvez l'obtenir auprès de https://github.com/fingolfin/git-remote-hg . Enfin, il y a encore un autre concurrent récent, git-cinnabar, en utilisant une approche complètement différente en interne (bien que si cela ne vous intéresse pas, son utilisation est plus ou moins la même que pour les autres implémentations de git-remote-hg). Je ne l'ai pas encore essayé moi-même, mais vous pouvez le trouver sur https://github.com/glandium/git-cinnabar
hg-git peut apparemment être utilisé pour travailler avec git localement, avec un dépôt Mercurial distant: http://traviscline.com/blog/2010/04/27/using-hg-git-to-work-in -git-and-Push-to-hg /
Ne manquez pas les commentaires là-bas aussi.
Quelqu'un a déjà mentionné deux git-remote-hg, mais en voici un nouveau:
Support de pont dans git pour Mercurial et Bazaar
Il a plus de fonctionnalités et devrait fonctionner de manière plus fiable que celui de msysgit, mais surtout; vous n'avez besoin d'aucune dépendance ou d'une construction git personnalisée. Copiez simplement dans votre $ PATH , et c'est tout.
Il a des tests approfondis pour vérifier que la sortie est exactement la même que hg-git, donc cela devrait fonctionner au moins aussi.
Il y a un nouveau projet qui accomplit exactement cela:
Il fait la chose bidirectionnelle bien intégrée.
Je pense qu'il n'y a vraiment pas beaucoup d'incitation à en créer un. Personne ne sera horriblement handicapé en devant utiliser l'un sur l'autre; ils sont tous les deux DVCS. Bien sûr, tout le monde a probablement sa préférence, mais ils vont généralement le sucer et utiliser l'autre s'ils le doivent. Je suppose que hg-git est né parce que git est très largement utilisé, alors que beaucoup moins de projets ont adopté hg.
En revanche, si un projet utilise svn ou cvs, toute personne qui a un goût du DVCS va avoir du mal - et ils voudront cet utilitaire git-svn/hg-svn. Il y a encore beaucoup de projets utilisant cvs/svn, donc beaucoup de demande.
Vous avez probablement raison de dire que ce serait une chose utile à avoir, en supposant que l'un des deux ne gagne pas lentement l'autre (git a vraiment une base d'utilisateurs beaucoup plus grande, je crois).
Vous avez également raison de dire qu'il n'y a pas de gros obstacles techniques - hg-git est bidirectionnel, il est donc clairement possible de mapper les informations entre les deux.