Tire a Hg repo de Git repo que es el mismo proyecto pero ha perdido la historia

Mi escenario es el siguiente.

El proyecto del que he clonado fue originalmente versionado usando Mercurial y tengo un clon de ese repository original con toda su historia. En cierto momento, el propietario del proyecto decidió mudarse a GitHub, pero perdió toda la historia en la mudanza, por lo que este nuevo repository, aunque es una continuación del proyecto anterior, está comenzando nuevamente de la revisión 0.

Quiero seguir con Hg, y Hg-Git obviamente me permitirá sacar del repository de Git, pero lo que no sé cómo hacer es unir al jefe del repository de Hg con la queue del repository de Git para Puedo seguir tirando actualizaciones regulares como antes. La confirmación real en Git que coincide con el jefe del repository de Hg no es la primera confirmación, por lo que no es la punta de la queue.

Pensé que hg convert y –splicemap podrían ser útiles, pero cuanto más leo sobre él, less parece una solución para mí.

¿Alguien puede ofrecer alguna sugerencia sobre cómo puedo lograr esto?


Actualizar
Solo por la información de cualquiera que intente hacer algo similar, finalmente logré el resultado que quería pero fue un path largo y tortuoso, y resultó que la conversión de hg y el splicemap eran la respuesta después de todo.

  1. Bajé el repo de Git de Github con el complemento hg-git.
  2. Luego lo cloné en un nuevo repository y saqué los contenidos del repository de Hg relacionados pero desconectados usando hg pull –force .
    Así que ahora tengo un repository con 2 twigs distintas de desarrollo que no tienen antepasado común en lo que respecta al repository, voy a referirme a esto como la hidra .
  3. Usando hg convert y splicemap me uní a las twigs en el punto coincidente en el historial en un nuevo repository, y luego ejecuté hg strip para deshacerme de los bits innecesarios.
  4. El truco, sin embargo, fue que el repository original de Git se actualizará y quería poder incorporar los nuevos cambios a este repository compartido.
    ¿La solución? Lotes de files
    Sí, escuchaste bien, files por lotes.
    La solución fue efectivamente un set de 3, primero para sacar de Github al repository que solo contiene el repository de Git. Segunda extracción del repo de Git a la hidra (la fuente de Hg no va a cambiar, así que no es necesario que tire de eso otra vez). Tercero, vuelva a ejecutar el command hg convert para que actualice el repository unido con la nueva información de la hidra.

Es desagradable, es largo y fue una pesadilla establecerlo, pero ahora funciona limpiamente y mi repository final es de un tamaño pnetworkingecible y razonable.

Nunca lo intenté, pero tal vez manipular el file git-map en /.hg del bridge-repo podría funcionar. Lo probaría así:

  1. Digamos que la sugerencia de Hg Repo es la raíz de Git Repo.
  2. Clona el repo de Git a través de hg-git solo hasta la raíz (eso es posible con Git, ¿no?).
  3. Extraiga todas las confirmaciones del repository original de Hg en el clon hg-git.
  4. Elimina la raíz solitaria, pero anota el hash completo de esta raíz.
  5. Anote el hash completo de la sugerencia de Hg Repo (también la punta del clon hg-git ahora).
  6. Edite /.hg/git-mapfile. Solo debe contener una input con el hash de la raíz solitaria en un lado (debe estar a la derecha). Reemplace este hash con el de la punta. No reemplace el otro lado (izquierda), ya que es el hash del object Git commit correspondiente.
  7. "hg pull". Si la teoría se cumple, esto agregará los nuevos nodos Git a los nodos Hg antiguos.

Podría ser una completa tontería, pero al less las versiones más antiguas ("más tontas") de hg-git simplemente determinaban los objects git necesarios a través de este file de map. Entonces valdría la pena intentarlo …