Interopérabilité Git avec un référentiel Mercurial

J'utilise GIT sur un Mac. Assez dit. J'ai les outils, j'ai l'expérience. Et je veux continuer à l'utiliser. Pas de guerres ici ...

Le problème est toujours lié à l'interopérabilité. La plupart des gens utilisent SVN, ce qui est génial pour moi. Git SVN fonctionne immédiatement et est une solution sans fioritures. Les gens peuvent continuer à utiliser SVN avec plaisir et je ne perds pas mon flux de travail ni mes outils.

Maintenant ... Certains gars viennent avec Mercurial. Bien pour eux: ils ont leurs raisons. Mais je ne trouve aucun GIT HG prêt à l'emploi. Je ne veux pas passer à HG, mais j'ai encore besoin d'interopérer avec leur référentiel.

Certains d'entre vous connaissent une solution simple pour cela?

Mise à jour de juin 2012. Actuellement, il semble y avoir les méthodes suivantes d'interopérabilité Git / Hg lorsque le développeur souhaite travailler du côté git:

1. Installez Mercurial et l' extension hg-git . Vous pouvez le faire en utilisant votre gestionnaire de paquets ou avec easy_install hg-git. Assurez-vous ensuite que les éléments suivants se trouvent dans votre ~ / .hgrc:

   [extensions]
   hggit = 
   

   Vous pouvez voir quelques références qui parlent de spécifier l' bookmarksextension ici aussi, mais cela a été intégré à Mercurial depuis la v 1.8. Voici quelques conseils sur l'installation de hg-git sous Windows .

   Une fois que vous avez hg-git, vous pouvez utiliser des commandes à peu près comme Abderrahim Kitouni posté ci-dessus . Cette méthode a cependant été affinée et peaufinée depuis 2009, et il existe un wrapper convivial: git-hg-again . Cela utilise le répertoire toplevel comme répertoire de travail pour Mercurial et Git en même temps. Il crée un signet Mercurial qu'il synchronise avec la pointe de la defaultbranche (sans nom) dans le référentiel Mercurial, et il met à jour une branche Git locale à partir de ce signet.

2. git-remote-hg est un wrapper différent, également basé sur l'hg-gitextensionMercurial. Cela utilise également lesgit-remote-helpersprotocoles (d'où son nom). Il utilise le répertoire toplevel uniquement pour un répertoire de travail Git; il garde son référentiel Mercurial nu. Il maintient également un deuxième référentiel Git nu pour rendre la synchronisation entre Git et Mercurial plus sûre et plus idiomatique.

3. Le script git-hg (précédemment géré ici ) utilise une méthode différente, basée sur hg-fast-exportle projet d'exportation rapide . Comme la méthode 2, cela conserve également un référentiel Mercurial nu et un référentiel Git nu supplémentaire.

   Pour tirer, cet outil ignore les signets Mercurial et importe à la place chaque branche Mercurial nommée dans une branche Git, et la branche Mercurial par défaut (sans nom) dans master.

   Certains commentaires décrivent cet outil comme étant hg-> git uniquement, mais il prétend avoir fusionné dans git-> hg push support le 7 décembre 2011. Comme je l'explique dans une revue de ces outils , cependant, la façon dont cet outil essaie de mettre en œuvre le support push ne semble pas être réalisable.

4. Il existe également un autre projet appelé git-remote-hg . Contrairement à la version répertoriée ci-dessus, celle-ci ne repose pas sur hg-git, mais accède directement à l'API Mercurial Python. À l'heure actuelle, son utilisation nécessite également une version corrigée de git. Je n'ai pas encore essayé ça.

5. Enfin, Tailor est un projet qui convertit progressivement une variété de VCS différents. Il semble que le développement de cela ne sera pas poursuivi de manière agressive.

Les trois premières de ces approches semblaient suffisamment légères pour me persuader d'enquêter. J'avais besoin de les modifier de certaines façons pour les faire fonctionner sur ma configuration, et j'ai vu quelques façons de les peaufiner davantage pour les améliorer, puis je les ai encore peaufinées pour les faire se comporter plus comme les autres afin que je puisse évaluer les plus efficacement. Ensuite, j'ai pensé que d'autres pourraient aimer avoir ces ajustements aussi, pour faire la même évaluation. J'ai donc créé un package source qui vous permettra d'installer mes versions de l'un des trois premiers outils. Il devrait également prendre soin d'installer les hg-fast-exportpièces nécessaires . (Vous devez installer hg-gitvous-même.)

Je vous encourage à les essayer et à décider par vous-même de ce qui fonctionne le mieux. Je serai heureux d'entendre parler de cas où ces outils se brisent. J'essaierai de les synchroniser avec les changements en amont et de m'assurer que les auteurs en amont sont conscients des ajustements que je pense utiles.

Comme je l'ai mentionné ci-dessus, lors de l'évaluation de ces outils, je suis arrivé à la conclusion qui git-hgn'est utilisable que pour tirer de Mercurial, pas pour pousser.

De manière similaire, voici quelques comparaisons / manuels de traduction utiles entre Git et Mercurial, dans certains cas destinés aux utilisateurs qui connaissent déjà Git:

• Mercurial pour les utilisateurs de Git
• Git et Mercurial - Comparaison et contraste
• Quelle est la différence entre Mercurial et Git
• Mercurial et Git: une comparaison technique
• Git hg rosetta stone
• Codage Homebrew: Mercurial
• Blog de Francisoud: Git vs Mercurial (hg)
• Git vs Mercurial

Il y a un nouveau git-remote-hg qui fournit un support natif:

Prise en charge des ponts dans Git pour Mercurial et Bazaar

Copiez simplement git-remote-hg dans votre $ PATH, rendez-le exécutable, et c'est tout, pas de dépendances (autres que Mercurial):

git clone hg::https://www.mercurial-scm.org/repo/hg/

Vous devriez pouvoir le pousser et le retirer comme s'il s'agissait d'un référentiel Git natif.

Lorsque vous appuyez sur de nouvelles branches Git, des signets Mercurial sont créés pour eux.

Voir le wiki git-remote-hg pour plus d'informations.

Vous devriez pouvoir utiliser hg-git .

hg clone <hg repository>

éditez ~/.hgrcet ajoutez:

[extensions]
hgext.bookmarks =
hggit =

créez un signet pour avoir un masterin git:

cd <repository>
hg bookmark -r default master

modifier .hg/hgrcdans le référentiel et ajouter:

[git]
intree = true

vous pouvez maintenant créer le dépôt git:

hg gexport

et vous pouvez utiliser le répertoire résultant comme un clone git. tirer de mercurial serait:

hg pull
hg gexport

et poussant au mercure:

hg gimport
hg push

(Oui, vous devez utiliser hg avec ce workflow mais votre piratage sera tout en git)

PS Si vous avez un problème avec ce flux de travail, veuillez déposer un bogue.

Vous pouvez essayer hg2git, qui est un script python et fait partie de l'exportation rapide, que vous pouvez trouver sur http://repo.or.cz/w/fast-export.git .

Vous devrez cependant installer mercurial.

Étant donné que hg-git est un pont à deux voies, il vous permettra également de pousser les changements de Git vers Mercurial.

Plugin Hg-Git Mercurial . Je ne l'ai pas essayé moi-même, mais ça vaut peut-être la peine d'être vérifié.

J'ai eu un grand succès avec git-hgde https://github.com/cosmin/git-hg (nécessite l' installation de travail hg, aussi). Il prend en charge la récupération, la traction et la poussée et est plus stable pour moi que hg-git(fonctionnalités similaires de hgà git).

Voir https://github.com/cosmin/git-hg#usage pour des exemples d'utilisation. L'interface utilisateur est très similaire à git-svn.

Le git-hgrequiert un espace disque supplémentaire pour chaque dépôt hg cloné. L'implémentation utilise un clone mercurial complet, un clone nu git supplémentaire et le dépôt git réel. L'espace disque requis représente environ 3 fois l'utilisation normale de git only. Les copies supplémentaires sont stockées sous le .gitrépertoire de votre répertoire de travail (ou emplacement indiqué par GIT_DIRcomme d'habitude).

Remarque: Le problème de base qui git-hgtente de résoudre est qu'il n'y a pas de mappage 1: 1 entre les entités gitet hg. Le plus gros problème est le décalage d'impédance entre les branches git et les branches hg sans nom et les branches nommées hg et les signets hg (tous ceux-ci ressemblent beaucoup à des branches pour les gitutilisateurs). Un problème connexe est celui qui hgessaie d'enregistrer le nom de la branche nommée d'origine dans l'historique des versions, par opposition à git où le nom de la branche n'est ajouté qu'au message de validation du modèle par défaut.

Tout outil qui prétend créer un pont interopérable entre gitet hgdevrait expliquer comment il va gérer cette correspondance d'impédance. Vous pouvez alors décider si la solution sélectionnée correspond à vos besoins.

La solution qui git-hgconsiste à supprimer tous les signets hg et à convertir les branches nommées en branches git. De plus, il définit la branche git master sur la branche hg sans nom par défaut.

J'ai essayé hggit. Fonctionne pour moi, car je dois faire face au travail des git'ers et des hg'ers. Surtout pour les avis, c'est super.

Un problème / avertissement mineur à ce sujet:

J'ai essayé de cloner un référentiel de noyau Linux stable avec hg. Ces référentiels sont maintenus dans git et contiennent généralement un grand nombre de fichiers.

C'était très lent. Il m'a fallu 2 jours pour cloner entièrement et mettre à jour une copie de travail.

J'ai essayé à nouveau git-hg de cosmin et git-hg-d'abourget sur le repo hg de mutt , il semble que le dernier respecte bien l'ordre de fusion, le premier est un peu aléatoire. Vous pouvez le voir sur les captures d'écran ci-dessous.

Un graphique d'historique de fusion de mutt importé par git-hg de cosmin :

Un graphique d'historique de fusion de mutt importé par git-hg-again d' abourget :

Le graphique historique actuall tracé par hgk sur le référentiel hg de mutt:

Comme vous pouvez le voir ci-dessus, le deuxième graphique de git-hg-again d' abourget est très proche du graphique hgk d'origine et reflète en fait le flux de travail réel du mutt.

Un inconvénient de git-hg-again que j'ai trouvé est qu'il n'ajoute pas de télécommande `` hg '', importe plutôt toutes ses références sous forme de balises locales, git-hg a une merveilleuse télécommande `` hg '' qui représente le dépôt hg en amont.

La synchronisation bidirectionnelle hg-git (et git-git, hg-hg) est également possible avec le service Git-hg Mirror . Il utilise hg-git (entre autres) dans les coulisses et son code est également open source.

Avis de non - responsabilité : je suis de la société derrière elle.