Pull to Hg repo из Git repo, который является тем же проектом, но потерял историю

Мой сценарий таков.

Проект, из которого я клонировал, изначально был создан с использованием Mercurial, и у меня есть клон этого оригинального репо со всей его историей. В определенный момент времени владелец проекта решил перейти на GitHub, но потерял всю историю в движении, поэтому этот новый репозиторий, хотя и является продолжением старого проекта, фактически начинает заново с ревизии 0.

Я хочу придерживаться Hg, и Hg-Git, очевидно, позволит мне вытащить из репозитория Git, но я не знаю, как это сделать, это соединить головку репозитория Hg с хвостом репозитория Git, так что Я могу просто продолжать рушить регулярные обновления, как и раньше. Фактический коммит в Git, соответствующий заголовку репозитория Hg, - это не первый коммит, так что это не конец хвоста.

Я подумал, что hg convert и --splicemap могут быть полезны, но чем больше я об этом читаю, тем меньше это выглядит для меня решением.

Может кто-нибудь предложить какие-либо предложения относительно того, как я могу этого добиться?


Обновить
Просто для информации любого, кто может пытаться сделать что-то подобное, мне наконец удалось достичь желаемого результата, но это был долгий и извилистый путь, и оказалось, что hg convert и splicemap были ответом в конце концов.

  1. Я снял репозиторий Git с Github с помощью плагина hg-git.
  2. Затем я клонировал это в новый репо и извлек связанное, но отключенное содержимое репозитория Hg, используя hg pull --force.
    Так что теперь у меня есть репо с двумя разными ветвями разработки, которые не имеют общего предка в том, что касается репо, я буду называть это гидрой.
  3. Используя hg convert и splicemap, я объединил ветви в точке сопоставления в истории в новое хранилище, а затем запустил hg strip, чтобы избавиться от ненужных ненужных битов.
  4. Однако хитрость заключалась в том, что оригинальное репозиторий Git будет обновлено, и я хотел иметь возможность вносить новые изменения в это объединенное репо.
    Решение? Пакетные файлы.
    Да, вы слышали правильно, пакетные файлы.
    Решением был набор из 3-х, сначала перетащивший из Github в репо, который просто содержит Git-репо. Второй вытащил из репозитория Git в гидру (источник ртути не изменится, поэтому мне не нужно больше от этого отрываться). В-третьих, повторно запустили команду hg convert, чтобы она обновила объединенный репозиторий новой информацией из гидры.

Это неприятно, оно давно затянуто, и это было немного страшно, но сейчас все работает чисто, и мой финальный репо имеет предсказуемый и разумный размер.

1 ответ

Решение

Никогда не пробовал этого, но, возможно, манипулирование git-mapfile в /.hg моста-репо могло бы сработать. Я бы попробовал это так:

  1. Допустим, подсказка Hg-репо - это корень Git-репо.
  2. Клонируйте репозиторий Git через hg-git только до корня (это возможно с Git, верно?).
  3. Вытащите все коммиты из оригинального репозитория Hg в клон hg-git.
  4. Уберите одинокий корень, но запишите полный хэш этого корня.
  5. Запишите полный хэш подсказки репозитория Hg (также теперь и подсказку клона hg-git).
  6. Отредактируйте /.hg/git-mapfile. Он должен содержать только одну запись с хешем одинокого корня на одной стороне (должен быть справа). Замените этот хэш на один из кончиков. Не заменяйте другую сторону (слева), так как это хэш соответствующего объекта коммита Git.
  7. "HG тянуть". Если теория верна, это добавит новые узлы Git к старым узлам Hg.

Может быть, полная чепуха, но по крайней мере старые ("тупые") версии hg-git просто определяли необходимые объекты git через этот файл карты. Так что стоит попробовать...

Другие вопросы по тегам