Git совершить неполное слияние - PullRequest
0 голосов
/ 24 апреля 2019

Есть ли способ совершить неполное слияние?Я решил половину конфликтов.Другая половина моего коллеги гораздо лучше квалифицирована для работы.

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

1 Ответ

1 голос
/ 24 апреля 2019

Короткий ответ - нет, это невозможно.

Я хотел поработать над сценарием, чтобы подобраться как можно ближе. Во время разрешения конфликта в индексе есть три копии каждого файла, плюс четвертая в рабочем дереве. (Добавьте неизменяемую копию в 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 , смысл этого скрипта будет заключаться в том, чтобы упростить транспортировку выполняющегося слияния, независимо от того, какой скрипт вам нужен, необходимо предоставить механизм и некоторые четкие инструкции для этого. .

...