Короткий ответ - нет, это невозможно.
Я хотел поработать над сценарием, чтобы подобраться как можно ближе. Во время разрешения конфликта в индексе есть три копии каждого файла, плюс четвертая в рабочем дереве. (Добавьте неизменяемую копию в HEAD
, и, по сути, пять активных копий каждого файла - но нам нужно сохранить только четыре из них, поскольку одну в HEAD
нельзя изменить. ) Можно было бы сохранить каждый из них способом, очень похожим на то, что делает git stash
, что позволило бы передавать «спрятанное незавершенное слияние» через обычные механизмы Git. 1 Это будет охватывать большинство случаев. Однако во время слияния с разрешением частично в индексе есть некоторая специальная информация - записи отмены «REUC», которые невозможно сохранить вообще, и все слияния не могут записать некоторые важные информация о конфликтах высокого уровня (например, конфликты переименования / переименования), которые действительно должны быть как-то раскрыты перед этим.
Если вам не нужны записи отмены, этот скрипт, который я не написал, может сработать, но, увы, я его не написал. :-) Основная идея, однако, заключается в том, чтобы читать / копировать текущий (конфликтующий слиянием) индекс в три или четыре неконфликтных временных копии индекса: по одной для каждой записи этапа 1, по одному для каждой записи этапа 2 и один для каждый этап-3 записи. Нам также нужен один для всех записей этапа 0, хотя, возможно, здесь можно использовать исходный индекс. Добавьте последний временный индекс для хранения фактического состояния рабочего дерева w
, в комплекте с файлами с маркерами конфликта (и, возможно, u
фиксация для неотслеживаемых файлов в случае, если кто-то использует git mergetool
?). Сделайте коммиты из всех файлов временного индекса, связав их некоторым полезным способом, и HEAD
сделайте так же, как git stash
делает шкатулку из своих i
и w
коммитов. Затем выполните git reset --hard
так же, как git stash
.
Чтобы восстановить конфликтующее состояние, сначала убедитесь, что все чисто, затем прочитайте каждый коммит во временный индекс. Используйте полученные индексные файлы для создания нового конфликтующего индекса с записями на этапах 0, 1, 2 и 3, в зависимости от ситуации. Используйте фиксацию рабочего дерева, чтобы установить состояние рабочего дерева из коммита сохраненного слияния w
(возможно, сначала сделайте это на самом деле).
1 Технически возможно транспортировать git stash
коммиты между репозиториями сегодня, но интерфейсная и внутренняя работа git stash
делает его немного сложным. Поскольку, или, по крайней мере, a , смысл этого скрипта будет заключаться в том, чтобы упростить транспортировку выполняющегося слияния, независимо от того, какой скрипт вам нужен, необходимо предоставить механизм и некоторые четкие инструкции для этого. .