tag tab practices delete create commits commands best git version-control mercurial interop dvcs

tab - git tag commits



Interoperabilidad Git con un repositorio Mercurial. (10)

Yo uso GIT en una Mac. Basta de charla. Tengo las herramientas, tengo la experiencia. Y quiero seguir usándolo. No hay guerras aquí ...

El problema es siempre con la interoperabilidad. La mayoría de la gente usa SVN, lo cual es genial para mí. Git SVN trabaja fuera de la caja, y es una solución sencilla. La gente puede continuar utilizando SVN con gusto y no pierdo mi flujo de trabajo ni mis herramientas.

Ahora ... Algunos muchachos vienen con Mercurial. Bien por ellos: tienen sus razones. Pero no puedo encontrar ningún GIT HG listo para usar. No quiero cambiar a HG, pero aún necesito interoperar con su repositorio.

¿Alguno de ustedes sabe una solución simple para esto?

Actualización de junio de 2012. Actualmente, parece que existen los siguientes métodos para la interoperabilidad de Git / Hg cuando el desarrollador desea trabajar desde el lado de git:

  1. Instala Mercurial y la extensión hg-git . Puede hacer esto último usando su administrador de paquetes, o con easy_install hg-git . Luego asegúrese de que lo siguiente esté en su ~ / .hgrc:

    [extensions] hggit =

    Es posible que vea algunas referencias que hablan sobre la especificación de la extensión de bookmarks aquí también, pero que se ha incorporado en Mercurial desde la versión 1.8. Aquí hay algunos consejos sobre la instalación de hg-git en Windows .

    Una vez que tenga hg-git, puede usar comandos aproximadamente como Abderrahim Kitouni publicado anteriormente . Sin embargo, este método ha sido refinado y ajustado desde 2009, y hay una envoltura amigable: git-hg-again . Esto utiliza el directorio de nivel superior como un directorio de trabajo para Mercurial y Git al mismo tiempo. Crea un marcador de Mercurial que se mantiene sincronizado con la punta de la rama default (sin nombre) en el repositorio de Mercurial, y actualiza una rama Git local de ese marcador.

  2. git-remote-hg es un contenedor diferente, también basado en la extensión Mercurial hg-git . Esto también hace uso de los protocolos git-remote-helpers (de ahí su nombre). Utiliza el directorio de nivel superior solo para un directorio de trabajo de Git; mantiene su repositorio Mercurial al descubierto. También mantiene un segundo repositorio de Git para hacer que la sincronización entre Git y Mercurial sea más segura y más idiomática.

  3. El script git-hg (anteriormente mantenido here ) utiliza un método diferente, basado en hg-fast-export del proyecto de exportación rápida . Al igual que el método 2, esto también mantiene un repositorio Mercurial y un repositorio Git adicional.

    Para tirar, esta herramienta ignora los marcadores de Mercurial y, en su lugar, importa cada rama de Mercurial con nombre a una rama de Git, y la rama de Mercurial predeterminada (sin nombre) a Master.

    Algunos comentarios consideran que esta herramienta es solo hg-> git, pero afirma haberse fusionado en git-> hg push support el 7 de diciembre de 2011. Sin embargo, como explico en una revisión de estas herramientas , la forma en que esta herramienta intenta implementar empujar el apoyo no parece ser viable.

  4. También hay otro proyecto llamado git-remote-hg . A diferencia de la versión mencionada anteriormente, esta no se basa en hg-git, sino que accede directamente a la API de Mercurial Python. Por el momento, su uso también requiere una versión parcheada de git. No he intentado esto todavía.

  5. Finalmente, Tailor es un proyecto que se convierte de forma incremental entre una variedad de VCS diferentes. Parece que el desarrollo de esto no continuará agresivamente.

Los tres primeros de estos enfoques parecían lo suficientemente livianos como para persuadirme a investigar. Necesitaba ajustarlos de alguna manera para que funcionen en mi configuración, y vi algunas formas de modificarlos para mejorarlos, y luego los ajusté aún más para hacer que se comportaran más como otros para poder evaluarlos. ellos mas efectivamente Entonces pensé que a otros les gustaría tener estos ajustes también, para hacer la misma evaluación. Así que he creado un paquete fuente que te permitirá instalar mis versiones de cualquiera de las tres primeras herramientas. También debe encargarse de instalar las piezas necesarias hg-fast-export . (Necesitas instalar hg-git por tu cuenta).

Te animo a probarlos y decidir por ti mismo lo que funciona mejor. Estaré encantado de escuchar sobre los casos en que estas herramientas se rompen. Trataré de mantenerlos sincronizados con los cambios en sentido ascendente, y para asegurarme de que los autores anteriores estén al tanto de los ajustes que creo que son útiles.

Como mencioné anteriormente, al evaluar estas herramientas, llegué a la conclusión de que git-hg solo se puede usar para tirar de Mercurial, no para empujar.

A propósito, aquí hay algunas comparaciones / manuales de traducción útiles entre Git y Mercurial, en algunos casos dirigidos a usuarios que ya conocen Git:

Dado que hg-git es un puente de dos vías, también le permitirá impulsar los conjuntos de cambios de Git a Mercurial.

Deberías poder utilizar hg-git .

hg clone <hg repository>

~/.hgrc y agrega:

[extensions] hgext.bookmarks = hggit =

crea un marcador para que tengas un master en git:

cd <repository> hg bookmark -r default master

Edite .hg/hgrc en el repositorio y agregue:

[git] intree = true

Ahora puedes crear el repositorio git:

hg gexport

y puedes usar el directorio resultante como un clon de git. Tirar de mercurial sería:

hg pull hg gexport

y empujando a mercurial:

hg gimport hg push

(Sí, necesitas usar hg con este flujo de trabajo, pero tu piratería será todo en git)

PD: Si tiene un problema con este flujo de trabajo, presente un error.

Han intentado hggit. Trabaja para mí, ya que tengo que hacer frente al trabajo de git''ers y hg''ers. Especialmente para las revisiones esto es genial.

Un pequeño problema / advertencia sobre ese tema:

He intentado clonar un repositorio estable de kernel de Linux con hg. Estos repositorios se mantienen en git y normalmente tienen una gran cantidad de archivos.

Fue muy lento Me tomó 2 días clonar completamente y actualizar una copia de trabajo.

Hay un nuevo git-remote-hg que proporciona soporte nativo:

Puente de apoyo en Git para Mercurial y Bazar.

Solo copie git-remote-hg a su $ PATH, conviértalo en ejecutable, y eso es todo, no dependencias (aparte de Mercurial):

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

Debería poder empujar y tirar de él como si fuera un repositorio de Git nativo.

Cuando empujes nuevas sucursales de Git, se crearán marcadores de Mercurial para ellas.

Consulte la wiki de git-remote-hg para obtener más información.

He probado git-hg git-hg-again tanto en el repositorio hg de mutt , parece que el último respeta el orden de una fusión, el primero es un poco aleatorio. Se puede ver en las capturas de pantalla de abajo.

Un gráfico de historial de fusión de mutt importado por git-hg :

Un gráfico de historial de fusión de mutt importado por git-hg-again :

La gráfica de la historia de actuall trazada por hgk en el repositorio hg de mutt:

Como puede ver en el gráfico anterior, el segundo gráfico git-hg-again abourget está muy cerca del gráfico hgk original y en realidad refleja el flujo de trabajo real del mutt.

Una desventaja de git-hg-again que encontré es que no agrega un control remoto ''hg'', sino que importa todos sus refs como etiquetas locales, git-hg tiene un control remoto maravilloso ''hg'' que representa el repositorio hg en sentido ascendente.

He tenido un gran éxito con git-hg desde git-hg (también requiere una instalación funcional de hg ). Es compatible con búsqueda, extracción y empuje y es más estable para mí que hg-git (características similares de hg a git).

Consulte https://github.com/cosmin/git-hg#usage para ver ejemplos de uso. La interfaz de usuario es muy similar a git-svn .

El git-hg requiere espacio de disco adicional para cada repositorio hg clonado. La implementación utiliza un clon mercurial completo, un clon de git extra y el repositorio de git real. El espacio en disco requerido es aproximadamente 3 veces el uso normal de git. Las copias adicionales se almacenan debajo del directorio .git de su directorio de trabajo (o ubicación señalada por GIT_DIR como de costumbre).

Aviso: el problema básico que git-hg intenta resolver es que no hay una asignación 1: 1 entre git y hg . El mayor problema es el desajuste de impedancia entre las ramas de git y hg ramas sin nombre y las ramas de hg con nombre y los marcadores de hg (todos se parecen mucho a las ramas para usuarios de git ). Un problema relacionado es que hg intenta guardar el nombre original de la rama con nombre en el historial de versiones en lugar de git, donde el nombre de la rama solo se agrega al mensaje de confirmación de la plantilla de forma predeterminada.

Cualquier herramienta que pretenda crear un puente interoperable entre git y hg debe explicar cómo va a lidiar con esta impedancia. A continuación, puede decidir si la solución seleccionada se ajusta a sus necesidades.

La solución que utiliza git-hg es descartar todos los marcadores de hg y convertir las ramas con nombre en ramas de git. Además, establece la rama maestra de git en la rama hg predeterminada sin nombre.

La sincronización bidireccional de hg-git (y git-git, hg-hg) también es posible con el servicio Git-hg Mirror . Utiliza hg-git (entre otros) detrás de escena y su código también es de código abierto.

Descargo de responsabilidad : soy de la empresa detrás de ella.

Puede probar hg2git , que es un script de Python y es parte de fast-export, que puede encontrar en http://repo.or.cz/w/fast-export.git .

Tendrá que tener mercurial instalado sin embargo.