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

Esta es una pregunta que me ha estado molestando por un tiempo. Yo he hecho mi tarea y comprobado stackoverflow y encontré al menos estos dos temas acerca de mi pregunta: Git for Mercurial like git-svn y Git interoperability with a Mercurial repository Git como cliente mercurial? ¿Por qué no git-hg?

que he hecho algunas google serio para resolver este problema, pero hasta ahora sin suerte. También he leído el libro Git Internals, y el Mercurial Definitive Behind the Scenes para tratar de resolver esto. 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 sobre 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. Hay differences under the hood, pero ninguno de ellos debería evitar la creación de un cliente 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 entre los usuarios de git (y los 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 de DVCS para siempre?

Fuente

2010-03-26 Kai Inkinen

+35

@pajton: o porque 'git' es mucho mejor que' hg', ¿verdad? – Cascabel

git-hg existe (ahora). http://stackoverflow.com/questions/5225666/is-there-a-git-command-to-import-a-hg-repository –

hg-git y Pycon presentation del autor explicando su opinión sobre la situación. No estoy seguro de si se encontró con estos mientras buscaba en Google pero respondieron mis preguntas.

Fuente

2010-03-26 21:27:41

¿Alguien tiene una transcripción de esto? –

no conozco uno, pero me pareció bastante fácil seguir –

¡Gran presentación! Informativo y divertido de ver. De hecho, no había visto esto antes, ya que tiendo a evitar ver videos en línea. Lamentablemente, todavía no estoy satisfecho con la respuesta. Si la funcionalidad ya está allí, ¿por qué no tomar todo el camino? Tendré que darle una oportunidad a hggit, pero tal vez debería enviar un correo electrónico a los chicos de bitbucket ... –

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 va a estar dolido, y querrán la utilidad git-svn/hg-svn. Hay muchos proyectos usando cvs/svn todavía, por lo que hay mucha demanda.

Probablemente tenga 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 tiene 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.

Fuente

2010-03-26 20:58:46 Cascabel

Desde mi experiencia, git está ganando mucha atención en el campo, pero hasta ahora muchas empresas a las que he consultado están seleccionando mercurial over git. La razón más a menudo es que mercurial es más fácil de captar para alguien con antecedentes de svn/cvs, que es aproximadamente el 99% de todos los desarrolladores. Esto significa que una gran cantidad de VCS comerciales se están convirtiendo en mercurial, lo que efectivamente excluye a git. Para cualquiera que use git, mantener el servidor como SVN sería mejor, debido a git-svn. Desarrollar esto podría ser un buen truco de relaciones públicas para git y, por lo tanto, interesante para los desarrolladores de git, ¿no estás de acuerdo? –

@aapeli: Interesante. No he encuestado, pero mi lugar de trabajo usa git, y entre los proyectos de software libre, git parece ser mucho más popular. Es muy desafortunado (pero no sorprendente) que las empresas utilicen la facilidad de transición de cvs/svn como una razón principal: en un mundo ideal, elegirían el que mejor se adapte a sus necesidades y esperan que los desarrolladores aprendan a usarlo. . Y es cierto, cualquier cosa para que git sea más ampliamente adoptado sería bueno para el proyecto, pero el apoyo abrumador en el mundo del software libre probablemente siempre será un éxito suficiente para garantizar el futuro de git. – Cascabel

Supongo que muchas tiendas de Windows podrían elegir hg over git debido a problemas percibidos con el soporte de ventanas de git –

hg-GIT, aparentemente, puede ser utilizado para trabajar con Git local, con una cesión temporal de mercurio a distancia: http://traviscline.com/blog/2010/04/27/using-hg-git-to-work-in-git-and-push-to-hg/

no se pierda los comentarios allí también.

Fuente

2011-02-05 15:52:57

[solución de felipec] (http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/) ahora está integrado en Git, y funciona bien, por lo que se debe preferir – CharlesB

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

Una utilidad git-hg para hacer la salida y seguimiento de un acuerdo de recompra mercurial.

Un conjunto de scripts para retirar y rastrear un proyecto mercrial [sic].

Parece que no funciona bidireccionalmente (ver issue tracker).

Fuente

2011-02-07 07:27:50 akaihola

parece que alguien más ya lo agregó. Consulte [este tenedor] (https://github.com/ekohlwey/git-hg). – Albert

+14

Soy el autor original de git-hg. En realidad, es solo un conjunto de envoltorios de shell de exportación rápida que he utilizado para rastrear un repositorio de hg remoto. Como lo indicó Albert, alguien agregó soporte de inserción y yo fusioné ese tenedor hoy. Por alguna razón, debo haber estado perdiendo notificaciones por correo electrónico de GitHub porque tuve dos solicitudes de extracción abiertas hace unas semanas que nunca había notado hasta hoy. –

Como explico en detalle [aquí] (https://github.com/dubiousjim/yagh/blob/master/Evaluation.md), el método que Git-Hg usa para empujar a Mercurial no parece usarse en la práctica. Le dije a Cosmin sobre esto ya; Acabo de publicar este comentario aquí para ayudar a otros que terminan encontrando su camino a estas herramientas a través de los mismos caminos de búsqueda que hice. – dubiousjim

Hay un nuevo proyecto que lleva a cabo sólo eso:

https://github.com/abourget/git-hg-again

Se hace el bidireccional cosa muy bien integrado.

Fuente

2012-04-16 18:24:39 abourget

Cool. tendrá que verificarlo. Aunque últimamente ha empezado a sentir más y más proyectos se están convirtiendo en git y mercurial es cada vez menos interesante. Tal vez es solo mi perspectiva, pero aún así ... –

Gracias por esta herramienta. Publiqué una discusión detallada de esto [aquí] (https://github.com/dubiousjim/yagh) (vea especialmente la página "Evaluación"). – dubiousjim

[solución de felipec] (http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/) ahora está integrado en Git, y funciona bien, por lo que se debe preferir – CharlesB

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 continuación, se hace simplemente como esto:

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

ACTUALIZACIÓN: Por ahora no hay una tercera, 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, pero algunos parches para git (bajo revisión ahora) se pueden 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 todavía hay algunos puntos difíciles.

ACTUALIZACIÓN 3: actualmente tanto gitifyhg como git-remote-hg de Felipe 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 llamando al https://github.com/fingolfin/git-remote-hg. Finalmente, hay otro contendiente reciente, git-cinnabar, que utiliza un enfoque totalmente diferente internamente (aunque si no te importa, usarlo es más o menos lo mismo que para las otras implementaciones de git-remote-hg). Todavía no he probado a mí mismo, pero se puede encontrar en https://github.com/glandium/git-cinnabar

Fuente

2012-07-06 01:21:16 Max

en pycon 2013, el autor de gitifyhg sonaba bastante seguro. Dice que no se ha probado en Windows, así que lo estoy probando ahora. – Epu

gitifyhg es en realidad una bifurcación de git-remote-hg, y no creo que tampoco requiera hg-git (usan módulos Mercurial python directamente). El equipo que trabaja en gitifyhg parece ser más receptivo a los informes de errores que el tipo que originalmente desarrolló git-remote-hg, así que pasé a gitifyhg. –

Alguien ya se ha mencionado dos git-remote-HG, pero aquí está una nueva:

Bridge support in git for mercurial and bazaar

Tiene características más y debe trabajar 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 su $ PATH, y eso es todo.

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

Fuente

2012-11-13 02:46:19 FelipeC

Podría haber sido educado mencionar que usted es el autor de esas herramientas ... –

¿Cómo maneja 'git-remote-hg' la impedancia no coincidente entre hg branches y git branches (vea mi respuesta en http: // stackoverflow .com/a/11223644/334451 para más detalles)? –

'git-remote-hg' importa tanto las ramas nombradas como los marcadores de Mercurial, ya que los marcadores son lo mismo que las ramas de Git, un marcador 'foo' tiene una rama 'foo' en Git. Sin embargo, una rama llamada 'bar' recibe una rama 'branches/bar' en Git.Si empuja algo mientras se encuentra en la parte superior de esa rama, todos los commits obtienen la etiqueta 'bar', por lo que terminan en la rama llamada 'bar'. Además, hay un modo de compatibilidad hg-git, en el cual hacemos exactamente lo mismo que hg-git y agregamos código adicional al final de una confirmación que especifica la rama Mercurial con nombre. Por lo tanto, no se pierde información. – FelipeC

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

Respuesta

Cuestiones relacionadas