Interoperabilità git con un repository mercuriale

Uso GIT su un Mac. È stato detto abbastanza. Ho gli strumenti, ho l'esperienza. E voglio continuare a usarlo. Nessuna guerra qui ...

Il problema è sempre con l'interoperabilità. Molte persone usano SVN, il che è fantastico per me. Git SVN è pronto all'uso ed è una soluzione senza fronzoli. Le persone possono continuare a usare felicemente SVN e io non perdo il mio flusso di lavoro né i miei strumenti.

Ora ... Alcuni ragazzi vengono con Mercurial. Va bene per loro: hanno le loro ragioni. Ma non riesco a trovare nessun GIT HG pronto all'uso. Non voglio passare a HG, ma devo ancora interagire con il loro repository.

Qualcuno di voi ragazzi conosce una soluzione semplice per questo?

Aggiornamento da giugno 2012. Attualmente sembrano esserci i seguenti metodi per l'interoperabilità di Git / Hg quando lo sviluppatore vuole lavorare dal lato git:

1. Installa Mercurial e l' estensione hg-git . Puoi fare quest'ultimo usando il tuo gestore pacchetti o con easy_install hg-git. Quindi assicurati che quanto segue sia nel tuo ~ / .hgrc:

   [extensions]
   hggit = 
   

   Potresti vedere alcuni riferimenti che parlano anche della specifica bookmarksdell'estensione qui, ma che è stato integrato in Mercurial dalla v 1.8. Ecco alcuni suggerimenti sull'installazione di hg-git su Windows .

   Una volta che hai hg-git, puoi usare i comandi più o meno come Abderrahim Kitouni pubblicato sopra . Questo metodo è stato perfezionato e ottimizzato dal 2009, e c'è un wrapper amichevole: git-hg-again . Questo utilizza la directory di livello superiore come directory di lavoro per Mercurial e Git contemporaneamente. Crea un segnalibro Mercurial che mantiene sincronizzato con la punta del defaultramo (senza nome) nel repository Mercurial e aggiorna un ramo Git locale da quel segnalibro.

2. git-remote-hg è un wrapper diverso, anch'esso basato sull'estensione Mercurialhg-git. Questo fa inoltre uso deigit-remote-helpersprotocolli (da cui il suo nome). Utilizza la directory di livello superiore solo per una directory di lavoro di Git; mantiene nudo il suo repository Mercurial. Mantiene anche un secondo repository Git nudo per rendere la sincronizzazione tra Git e Mercurial più sicura e più idiomaticamente gitlike.

3. Il git-hg di script (precedentemente mantenuto qui ) utilizza un metodo diverso, sulla base hg-fast-exportdel progetto FAST-export . Come il metodo 2, anche questo mantiene un repository Mercurial nudo e un repository Git nudo aggiuntivo.

   Per il pull, questo strumento ignora i segnalibri Mercurial e importa invece ogni ramo Mercurial con nome in un ramo Git e il ramo Mercurial predefinito (senza nome) in master.

   Alcuni commenti considerano questo strumento solo come hg-> git, ma afferma di essersi unito al supporto push git-> hg il 7 dic 2011. Tuttavia, come spiego in una recensione di questi strumenti , il modo in cui questo strumento tenta di implementare il supporto push non sembra fattibile.

4. C'è anche un altro progetto chiamato git-remote-hg . A differenza della versione sopra elencata, questa non si basa su hg-git, ma accede direttamente all'API Mercurial Python. Al momento, usarlo richiede anche una versione patchata di git. Non l'ho ancora provato.

5. Infine, Tailor è un progetto che converte progressivamente tra una varietà di VCS diversi. Sembra che lo sviluppo di questo non sarà continuato in modo aggressivo.

I primi tre di questi approcci sembravano abbastanza leggeri da convincermi a indagare. Avevo bisogno di modificarli in qualche modo per farli funzionare sul mio setup, e ho visto alcuni modi per ottimizzarli ulteriormente per migliorarli, e poi li ho ulteriormente ottimizzati per farli comportarsi più uno come l'altro in modo da poter valutare più efficacemente. Poi ho pensato che anche altri avrebbero voluto avere queste modifiche, per fare la stessa valutazione. Quindi ho creato un pacchetto sorgente che ti consentirà di installare le mie versioni di uno dei primi tre strumenti. Dovrebbe anche occuparsi dell'installazione dei hg-fast-exportpezzi necessari . (Devi installare hg-gitda solo.)

Ti incoraggio a provarli e a decidere tu stesso cosa funziona meglio. Sarò felice di conoscere casi in cui questi strumenti si rompono. Cercherò di mantenerli sincronizzati con le modifiche a monte e di assicurarmi che gli autori a monte siano consapevoli delle modifiche che ritengo utili.

Come ho accennato in precedenza, nel valutare questi strumenti, sono giunto alla conclusione che git-hgè utilizzabile solo per estrarre da Mercurial, non per spingere.

Di conseguenza, ecco alcuni utili confronti / manuali di traduzione tra Git e Mercurial, in alcuni casi rivolti agli utenti che già conoscono Git:

• Mercurial per utenti Git
• Git e Mercurial - Confronto e contrasto
• Qual è la differenza tra Mercurial e Git
• Mercurial and Git: un confronto tecnico
• Git hg rosetta stone
• Codifica homebrew: mercuriale
• Blog di Francisoud: Git vs Mercurial (hg)
• Git vs Mercurial

C'è un nuovo git-remote-hg che fornisce supporto nativo:

Supporto bridge in Git per Mercurial e Bazaar

Basta copiare git-remote-hg sul tuo $ PATH, renderlo eseguibile, e basta, senza dipendenze (tranne Mercurial):

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

Dovresti essere in grado di spingere e estrarre da esso come se fosse un repository Git nativo.

Quando si spingono nuovi rami Git, verranno creati i segnalibri Mercurial per loro.

Vedi il wiki di git-remote-hg per maggiori informazioni.

Dovresti essere in grado di usare hg-git .

hg clone <hg repository>

modifica ~/.hgrce aggiungi:

[extensions]
hgext.bookmarks =
hggit =

crea un segnalibro in modo da avere un masterin git:

cd <repository>
hg bookmark -r default master

modifica .hg/hgrcnel repository e aggiungi:

[git]
intree = true

ora puoi creare il repository git:

hg gexport

e puoi usare la directory risultante come un clone git. tirando da mercuriale sarebbe:

hg pull
hg gexport

e spingendo a mercurial:

hg gimport
hg push

(Sì, devi usare hg con questo flusso di lavoro ma il tuo hacking sarà tutto in git)

PS In caso di problemi con questo flusso di lavoro, si prega di presentare un bug.

Puoi provare hg2git, che è lo script Python e fa parte dell'esportazione rapida, che puoi trovare su http://repo.or.cz/w/fast-export.git .

Tuttavia, dovrai installare mercurial.

Poiché hg-git è un bridge a due vie, ti consentirà anche di spostare i changeset da Git a Mercurial.

Plugin mercuriale Hg-Git . Non l'ho provato da solo, ma potrebbe valere la pena verificarlo.

Ho avuto un grande successo con git-hgda https://github.com/cosmin/git-hg (richiede anche l'installazione funzionante di hg). Supporta il recupero, il pull e il push ed è più stabile per me rispetto a hg-git(funzionalità simili dahg a git).

Consulta https://github.com/cosmin/git-hg#usage per esempi di utilizzo. L'interfaccia utente è molto simile agit-svn .

Lo git-hgrichiede più spazio su disco per ogni repo hg clonati. L'implementazione utilizza un clone completo, un clone bare git extra e l'effettivo repository git. Lo spazio su disco richiesto è circa 3 volte il normale utilizzo di git. Le copie extra sono archiviate sotto la .gitdirectory della directory di lavoro (o posizione indicata daGIT_DIR come al solito).

Avviso: il problema di base che git-hgtenta di risolvere è che non esiste un mapping 1: 1 tra gite hgfunzionalità. Il problema maggiore è la mancata corrispondenza dell'impedenza tra i rami git e i rami hg senza nome e i rami con nome hg e i segnalibri hg (tutti sembrano molto simili ai rami per gli gitutenti). Un problema correlato è quellohg tenta di salvare il nome del ramo con nome originale nella cronologia delle versioni invece di git in cui il nome del ramo viene aggiunto al messaggio di commit del modello per impostazione predefinita.

Qualsiasi strumento che afferma di creare un ponte interoperabile tra gite hgdovrebbe spiegare come gestirà questa corrispondenza di impedenza.Puoi quindi decidere se la soluzione selezionata soddisfa le tue esigenze.

La soluzione che git-hgutilizza è scartare tutti i segnalibri hg e convertire i rami con nome in rami git. Inoltre imposta il ramo master git sul ramo hg predefinito senza nome.

Ho provato Hggit. Funziona per me, dal momento che devo affrontare il lavoro di git'ers e hg'ers. Soprattutto per le recensioni è fantastico.

Un piccolo problema / avvertimento su questo argomento:

Ho provato a clonare un repository del kernel Linux stabile con hg. Questi repository sono mantenuti in git e in genere contengono un gran numero di file.

E 'stato molto lento Mi ci sono voluti 2 giorni per clonare e aggiornare completamente una copia funzionante.

Ho provato di nuovo Git-Hg di Cosmin e Git -Hg di abourget sia su hg repo di Mutt , sembra che il secondo rispetti bene l'ordine di fusione, che il primo sia un po 'casuale. Puoi vedere dagli screenshot qui sotto.

Un grafico cronologico di unione di mutt importato da gmin-hg di cosmin :

Un grafico cronologico di unione di mutt importato da gurg-hg-again di abourget :

Il grafico cronologico attuall tracciato da hgk sul repository hg di mutt:

Come puoi vedere da quanto sopra, il secondo grafico di git-hg-again di abourget è molto vicino al grafico hgk originale e in realtà riflette il vero flusso di lavoro del mutt.

Uno svantaggio di git-hg-again che ho riscontrato è che non aggiunge un telecomando 'hg', piuttosto importa tutti i suoi riferimenti come tag locali, git-hg ha un meraviglioso telecomando 'hg' che rappresenta il repository hg a monte.

La sincronizzazione bidirezionale di hg-git (e git-git, hg-hg) è anche possibile con il servizio Git-hg Mirror . Usa hg-git (tra gli altri) dietro le quinte e il suo codice è anche open source.

Disclaimer : vengo dalla società dietro di esso.