Una forma de sincronizar gg a git

Tengo un repository mercurial que contiene un proyecto de monolito que estoy tratando de dividir gradualmente. Mientras hacía eso, pensé que convertiría los nuevos subproyectos en git, por lo tanto, la synchronization en una dirección.

Algunos detalles más sobre lo que estoy haciendo:

  • el repository de hg y los nuevos repositorys de git se encuentran en una count de nube bitbucket privada.
  • Quiero mantener la historia de commits mientras hago la split
  • Todo nuestro desarrollo está basado en Windows (aunque estoy abierto a hacer la migration usando un sistema basado en Unix)
  • el repository inicial tiene 7 años, tiene todo tipo de tags, twigs cerradas, algunas twigs con caracteres de git no admitidos. Pero más importante, estoy contento de poder migrar solo el pnetworkingeterminado / maestro (si me ayuda a hacer el trabajo y no implica perder historial)
  • A medida que vamos convirtiendo gradualmente algunos proyectos dentro del repository (digamos que tengo 30 proyectos y quiero moverlos progresivamente) necesito hacer una manera de sincronizar de hg a git. No le temo a las fusiones y me complace mantener mi nuevo repository fuera del master y luego simplemente rebase con los cambios de hg sobre la marcha.
  • Me da la idea de que nuestro repo mercurial no está configurado correctamente (vi varias cabezas, etc.) pero estoy fuera de mi zona de confort cuando profundizo en la columna vertebral mercurial.

Hasta ahora he probado varias herramientas como fast-export, mercurial hg hggit plugin. Sin embargo, estoy luchando por encontrar buenas herramientas paso a paso. (y casi todos los enfoques en este hilo convierten el proyecto Mercurial en Git )

fast-export fue la herramienta que me dio los mejores resultados, pude migrar el proyecto una vez y todo, pero cuando intenté resincronizar empecé a tener errores, como la twig modificada en el exterior y varias cabezas.

Ahora que expliqué mi problema con más detalle, puedo formular la pregunta.

¿Cuál sería el mejor enfoque y las mejores herramientas para usar para poder hacer una migration unidireccional de hg a git?

Además, ¿cómo puedo asegurarme de que mi repository mercurial esté configurado correctamente para evitar posibles problemas al migrar a git?

Después de innumerables bashs, creo que encontré la manera de hacer lo que quería de una manera consistente. Para futuras references, estos fueron los pasos:

Instalación de herramientas necesarias

Instalar Git para Windows

Instale Tortoise HG o Mercurial independiente

Instalar Python 2.7 (fast-export no es compatible con Python 3.X en este momento)

Abra un indicador de Línea de command (Ejecutar como administrador).

Compruebe si puede ejecutar git, mercurial y python de la siguiente manera:

$ git $ mercurial $ python 

Si ha instalado los otros anteriores y está recibiendo errores, debe establecer la ruta, en mi caso solo tuve que hacerlo para Python. Así que lo hice:

 $ setx path "%path%;C:\Python27" 

reinicie el símbolo del sistema y todo debería estar listo para funcionar.

Instale la export rápida y clone los repositorys mercurial y git

Cree un directory limpio para que el trabajo se contenga allí (en mi caso, no utilizaré los repos de este directory para nada que no sea la synchronization de los proyectos). p.ej:

 c:\syncprojects 

Desde el interior c:\syncprojects start clonando fast-export

 $ git clone http://repo.or.cz/r/fast-export.git fast-export 

Luego, clona el proyecto mercurial

 $ hg clone https://bitbucket.org/user/mercurialrepo 

Luego, clona el proyecto git en el que quieras sincronizar

 $ git clone https://bitbucket.org/user/gitrepo gitrepo 

Me ayudó a tener un file de autores configurado correctamente, así que lo hice

 $ cd mercurialrepo $ hg log | grep user: | sort | uniq | sed 's/user: *//' > ../authors 

A continuación, abra el file de autores que se creó en c: \ syncprojects asegúrese de que el file de los autores coincida con algo similar a esto:

 bob=Bob Jones <bob@company.com> bob@localhost=Bob Jones <bob@company.com> bob <bob@company.com>=Bob Jones <bob@company.com> 

El siguiente paso es comenzar la migration real, para este paso me sentí más cómodo usando el git bash así que lo hice: En el explorador de Windows, haga clic derecho en la carpeta gitrepo y select "Git Bash aquí"

Luego hice que mi git repo local sensible a las mayúsculas y minúsculas, esto ayuda con el process, pero es una buena cosa tener, ya que en el pasado me encontré con problemas con carpetas sensibles a mayúsculas y minúsculas. Solo haz:

 git config core.ignoreCase false 

Dispara la synchronization

Finalmente lo hice:

 $ c:\syncprojects\fast-export\hg-fast-export.sh -rc:\syncprojects\mercurialrepo -A c:\syncprojects\authors --force 

Si todo va bien (y esto no necesariamente sucede todo el time, por varias razones tuve problemas con las cabezas en mercurial, problemas con los cambios locales en el repository git en el que bash sincronizar).

Todo lo que tenemos que hacer es verificar la cabeza y enviar los cambios a control remoto, como tal:

 $ git checkout HEAD $ git push -u origin master 

La próxima vez que quiera hacer una synchronization simplemente repita la parte final:

 $ c:\syncprojects\fast-export\hg-fast-export.sh -rc:\syncprojects\mercurialrepo -A c:\syncprojects\authors --force $ git checkout HEAD $ git push -u origin master 

Lamentablemente, los pasos no son tan rápidos como parece, pero esta fue la forma más concisa y consistente que encontré para abordar mi problema.

Algunos consejos más:

  • No fusioné ningún código nuevo para dominar en el repository git recién creado.
  • Hasta que esté totalmente satisfecho y pueda detener la synchronization, tendré una twig que contiene los cambios que hago en mi día a día y periódicamente fusionaré el maestro en esa twig.
  • No utilice estos repositorys para el desarrollo, exportar rápidamente los datos almacenados dentro de los repositorys que puedan perderse y hacer que el proyecto de networkingistribución sea muy difícil de lograr. Clone los repos en una location separada (y tenga cuidado al verificar otras sucursales en este repository por la misma razón).