Редактировать коммиты в репозитории HG и пометить как «закрытые» - PullRequest
1 голос
/ 13 января 2020

В настоящее время я имею дело с последствиями отказа BitGucket от поддержки HG. Мы собираемся дать hg-git попытку, потому что, хотя я и предпочитаю самодостаточность, мой босс еще не настолько зол на Atlassian, чтобы еще отойти от BB. Воспользуйтесь этой возможностью, чтобы очистить существующее хранилище HG перед конвертацией в GIT. Использовали hg convert для удаления некоторых случайно переданных двоичных файлов для уменьшения размера и т. Д. c.

Одна вещь, которую я заметил, это то, что у нас есть около двух десятков старых ветвей, которые технически «открыты», но были объединены в дефолт (без заключительного коммита, но им от месяца до года). Есть ли способ, которым я могу использовать инструмент типа hg histedit или во время от hg convert до go и специально отмечать старые головки веток --close-branch?

Просматривая документы, я могу найти кое-что о редактировании файлы, редактирование содержимого коммитов или изменение сообщений коммита, но ничего, что я могу найти, не упоминает метаданные о том, является ли коммит «закрытым». Я знаю, что это просто флаг для данного коммита, но я не знаю, как задним числом добавить его через любое расширение HG.

Редактировать : просто чтобы добавить немного ясности, Я понимаю, что могу просто обновить каждую из этих старых веток и добавить новую фиксацию, которая просто закрывает ветку. Там будет много свисающих, закрытых головок, но этого будет достаточно. Однако , я также должен затем дать каждому из них закладку в HG, иначе эти дополнительные «закрывающие» коммиты будут потеряны при преобразовании hg- git. Я бы предпочел не добавлять ~ 30 дополнительных веток в список ветвей git, просто чтобы они отображались как закрытые в HG без необходимости использовать revsets.

То, что я хочу сделать, не является "существенным" в грандиозной схеме репо, но я был бы удивлен, если бы редактирование метаданных коммита, чтобы сказать --close-branch было невозможно.

1 Ответ

2 голосов
/ 14 января 2020

Я проверил идею перебазирования с фиктивным репозиторием, и она, похоже, сработала.

Вот начальный репо:

enter image description here

А вот после перебазирования было состояние:

enter image description here

Я думаю, этот пример соответствует тому, о чем спрашивал вопрос. Первоначальный оборванный набор изменений закрытых ветвей был перемещен, чтобы предшествовать слиянию.

Я обновился до значения по умолчанию и выполнил следующую команду:

hg rebase --dest=4 --source=3 --keepbranches --config=ui.merge=internal:merge

Я фактически использовал Tortoise Workbench выполнить rebase, и это команда, которую он использовал. Таким образом, последний аргумент для ui.merge, вероятно, не является строго необходимым.

Как вы, возможно, уже заметили, с помощью hg convert действительно хорошая идея создавать новые клоны, когда вы go модифицируете репозиторий. Таким образом, если это испортится, у вас есть возможность легко отменить. Я, конечно, рекомендую этот подход и для этой операции.

...