tag remove practices create commits commands cliente best git mercurial interop

remove - Git como cliente mercurial? ¿Por qué no git-hg?



git tag remove (7)

Esta es una pregunta que me ha estado molestando por un tiempo. He hecho mi tarea y comprobé stackoverflow y encontré al menos estos dos temas sobre mi pregunta: Git for Mercurial como git-svn e interoperabilidad Git con un repositorio de Mercurial

He hecho un poco de Google para resolver este problema, pero hasta ahora sin suerte. También leí el libro de Git Internals y el Mercurial Definitive Behind the Scenes para tratar de resolverlo. Todavía estoy un poco desconcertado por qué no he podido encontrar ninguna herramienta de git-hg adecuada.

Desde mi punto de vista, git-svn es una de las características principales, por lo que he elegido usar git over mercurial también en el trabajo. Me permite usar un flujo de trabajo que me gusta, y nadie más necesita molestarse, si no les importa. Simplemente no veo el punto de usar el repo hg intermedio para convertir de ida y vuelta, como se sugiere en una de las cadenas.

De todos modos, por lo que he leído, hg y git parecen muy similares en el diseño conceptual. Existen diferencias bajo el capó , pero ninguna de ellas debería evitar la creación de un cliente de git para hg. Como me parece, las sucursales de rastreo remoto y las fusiones de pulpos hacen que git sea aún más poderoso que hg.

Entonces, la verdadera pregunta, ¿hay alguna razón real por la cual git-hg no existe (o al menos es muy difícil de encontrar)? ¿Existe alguna animosidad de los usuarios de git (y desarrolladores) hacia sus contrapartes de hg que ha causado la falta de la herramienta git-hg? ¿Alguno de ustedes tiene planes para desarrollar algo como esto y hacerlo público? Pude ser voluntario (aunque con C-skills muy débiles) para participar y hacer esto. Simplemente no poseo el conocimiento completo para comenzar esto yo mismo.

¿Podría ser esta la herramienta para terminar con todas las guerras DVCS para siempre?

Alguien ya mencionó dos git-remote-hg, pero aquí hay uno nuevo:

Soporte de puente en git para mercurial y bazar

Tiene más características y debería funcionar de manera más confiable que el msysgit, pero lo más importante; no necesita ninguna dependencia ni una compilación git personalizada. Solo copie a $ PATH , y eso es todo.

Tiene pruebas exhaustivas para verificar que la salida sea exactamente igual a hg-git, por lo que debería funcionar al menos también.

Creo que realmente no hay mucho incentivo para crear uno. Nadie va a estar horriblemente lisiado al tener que usar uno sobre el otro; ambos son DVCS. Claro, es probable que todos tengan su preferencia, pero generalmente la absorberán y usarán la otra si es necesario. Supongo que hg-git ha surgido porque git es muy utilizado, mientras que muchos menos proyectos han adoptado hg.

En contraste, si un proyecto está usando svn o cvs, cualquiera que haya probado DVCS estará sufriendo, y querrán la utilidad git-svn / hg-svn. Hay muchos proyectos usando cvs / svn todavía, por lo que hay mucha demanda.

Probablemente tengas razón en que sería útil tenerlo, suponiendo que uno de los dos no gana lentamente sobre el otro (creo que git tiene una base de usuarios mucho mayor).

También tienes razón en que no hay grandes obstáculos técnicos: hg-git es bidireccional, por lo que es posible mapear la información entre los dos.

Hay otro proyecto para realizar esto: git-remote-hg. En realidad dos de ellos, uno nativo (ver https://github.com/msysgit/msysgit/wiki/Guide-to-git-remote-hg ) y otro basado en hg-git (ver https://github.com/rfk/git-remote-hg ). El primero es mucho más rápido que el segundo, pero aún está incompleto y en desarrollo.

En realidad, hay asistentes remotos de git (como se llaman estas herramientas) para otros sistemas, ya sea que estén allí o en desarrollo; esto incluye soporte para Subversion, CVS, bazar e incluso MediaWiki.

La clonación de un repositorio de Mercurial a través de git se hace simplemente así:

git clone hg::https://hg.example.com/some-mercurial-repo

ACTUALIZACIÓN: Por ahora hay un tercero, también "nativo", es decir, el de Felipe que menciona en su respuesta aquí. Parece que pronto podría ser parte del directorio ''contrib'' de git: https://github.com/felipec/git-remote-hg Funciona sin necesidad de parches para git, aunque algunos parches para git (bajo revisión ahora ) se puede aplicar para mejorar la experiencia general del usuario.

ACTUALIZACIÓN 2: Y ahora hay otro contendiente, este en desarrollo bastante activo, y basado en el código de felipe: https://github.com/buchuki/gitifyhg - hasta ahora me funciona bastante bien, pero hay todavía algunos puntos ásperos.

ACTUALIZACIÓN 3: Tanto gitifyhg como git-remote-hg de Felipe actualmente no se mantienen activamente. Por el momento, hice una forma del código de Felipe con algunas correcciones, incluidas algunas para que funcione con las versiones recientes de Mercurial. Puede obtenerlo desde https://github.com/fingolfin/git-remote-hg . Finalmente, hay otro contendiente reciente, git-cinnabar , que utiliza un enfoque completamente diferente internamente (aunque si no te importa eso, usarlo es más o menos lo mismo que para las otras implementaciones de git-remote-hg). Todavía no lo he probado, pero puede encontrarlo en https://github.com/glandium/git-cinnabar

No lo he intentado, pero parece que hay un proyecto de git-hg . El proyecto se describe en la página y en el archivo README como:

Una utilidad git-hg para verificar y rastrear un repo mercurial.

Un conjunto de scripts para verificar y rastrear un proyecto mercérico [sic].

Sin embargo, no parece funcionar bidireccionalmente (ver el rastreador de problemas ).

hg-git y la presentación de Pycon del autor explicando su opinión sobre la situación. No estoy seguro de si los encontraste mientras buscabas en Google pero respondieron mis preguntas.