Повторно применить слияние после предварительной обработки веток? - PullRequest
Новая
       106

Повторно применить слияние после предварительной обработки веток?

0 голосов
/ 21 февраля 2019

У меня часто бывают ситуации, когда git merge содержит множество конфликтов, которые могут быть легко разрешены автоматически путем изменения одной из ветвей, чтобы она более точно соответствовала другой.К сожалению, я часто замечаю закономерности только после ручного разрешения десятков конфликтов, которые действительно нуждаются в ручном рассмотрении;Отмена коммита для применения скрипта будет означать его повторение.

Есть ли возможность вернуться от слияния к ветвям, не отбрасывая работы, потраченные на ручное разрешение конфликтов?

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

<<<<<<< HEAD
aaaaaaaa \todo{bbbbbbbb} cccccccc
=======
aaaaaaaa \TODO{bbbbbbbb} cccccccc
>>>>>>> other

Было бы легко разрешить этот конфликт, запустив однострочную строку sed для затронутых файлов, но я незнать инструмент, который затем удалял бы маркеры `<<<<<< ======= >>>>>>>".

Обычно рабочие процессы, приводящие к таким проблемамнестандартные ситуации, такие как:

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

  • Обратная ситуация, когда я хочу объединить сторонние изменения, доступные только в виде моментальных снимков, с моими источниками, при этом не известно общее предковое состояние: опыт в моддинге для любителей, когда он приводит к сотням линий, отличающихся толькона {sir/madam} становится {reg33?sir:madam}.

  • Файлы, независимо созданные в обеих ветвях путем экспорта из программы. Различные рабочие процессы приводили к почти идентичному состоянию, за исключениемнезначительный дифтакие особенности, как \todo[inline] против \todoinline, которые заглушают действительно важные различия при разрешении конфликтов слияния.

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

1 Ответ

0 голосов
/ 21 февраля 2019

Да: используйте rerere , re используйте re проводной re решения.

Если вы делаете git config rerere.enabled true вы включаете режим ~ auto ~, где он автоматически запускается, когда слияние заканчивается конфликтами, и снова, когда вы фиксируете результат.

Это будет удобно даже в вашем случае, когда вы не собираетесьcommit, потому что вы можете добраться до того места, о котором говорите, где вы сделали много разрешений и поняли, что можете избежать почти всего остального с помощью небольшой предварительной обработки, а затем выполните git rerere вручную перед прекращением слияния.

Когда выполняется rerere, он (a) запоминает новые конфликты и новые разрешения и (b) применяет запомненные разрешения к конфликтам, которые он видел раньше.Так что в вашей ситуации с включенным автоматическим режимом (я думаю, что это почти универсально для людей, которые помнят об этом), он бы заметил все конфликты и применил бы любые резолюции, которые вы показывали раньше, поэтому, когда вы доберетесь докогда вы сделали все, что могли, и собираетесь отступить и попытаться снова с предварительно обработанными данными, которые вы запускаете git rerere вручную, он увидит все новые разрешения, которые вы придумали, и проигнорирует оставшиеся конфликты, потому что он видел те, которые были дои у них ничего нет.Затем прервите слияние, выполните предварительную обработку, повторно запустите слияние, и автоматическое повторное сопоставление разрешит все конфликты, которые он может распознать, и заметит любые новые.

Будьте готовы, однако, Git не может распознать эти два разных текстаханки семантически идентичны, поэтому, если ваш prettyprinter разбивает строки и тому подобное, то даже если вы разрешите семантический конфликт в старом тексте, Git не сможет создать аналогичное текстовое изменение в новом тексте.

...