Как сделать так, чтобы git am / git apply работали "нечетко", как команда patch

Question

Я использовал git-format-patch и git-am, чтобы применить изменения из одного хранилища в другое. Файловые структуры одинаковы, но в репозитории, к которому я применяю изменения, есть некоторые изменения, которые приводят к тому, что большинство патчей завершается ошибкой. Но большинство фрагментов патча применяются с небольшим, но нечетким номером строк.

Насколько я могу сказать git-am apply очень строгое толкование, так что все эти патчи полностью отвергаются.

Итак, мой рабочий процесс стал

$ git am ../the-patch.patch
# Fails because the patch doesn't apply cleanly
$ patch -p1 < ../the-patch.patch
# Applies most of the hunks, leaves .rej files for the ones that conflict
# Fix the conflicting hunks manually
$ git am --continue

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

Запуск с флагом --reject создает файл .rej со всеми ссылками в файле, если есть конфликт, а это не то, что мне нужно.

Запуск с флагом --3way завершается неудачно с

fatal: sha1 information is lacking or useless (the-file.java).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.

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

Есть ли способ сделать git-am apply патч с нечетким соответствием, как это делает команда raw patch, и создавать только файлы .rej, содержащие фрагменты, которые потерпели неудачу?

Answer 1

Если я вас правильно понял, вы пытаетесь объединить репо кода 1 с другим, и у вас не получается выполнить некоторые части кода. Затем вы исправляете это вручную, и теперь вы хотите, чтобы оно было объединено без ошибок.

В этом случае вы должны использовать git rerere

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

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

git config --global rerere.enabled true

Answer 2

Исходя из потока, на который @Nick Desaulniers ссылается выше, похоже, что использование опции -3 для git apply / am будет работать, по крайней мере, до некоторой степени.

Например, вот мой вывод с патчем, который потерпел неудачу с git apply:

$ git apply < patch_file.patch error: patch failed: file_being_patched.txt:489 error: file_being_patched.txt: patch does not apply $ git apply -3 < patch_file.patch error: patch failed: file_being_patched.txt:489 Falling back to three-way merge... Applied patch to 'file_being_patched.txt' cleanly.

Обидно, что он все еще выдает ошибку (сложнее анализировать вывод в скриптах), и он не говорит, какой уровень fuzz был тем, что делает patch, так как уровень fuzz часто является хорошим показателем о том, могла ли команда исправления ошибиться.

Answer 3

Вы можете сделать следующее:

git am /path/to/some.patch
patch -p1 < /path/to/some.patch
git add .
git am --continue

Это применило бы патч и сохранило сообщение о коммите и т. Д.

Answer 4

Существует параметр --recount, но только для команды git-apply, поэтому теоретическая последовательность будет:

git mailsplit ...   
git mailinfo ...
git apply --recount ...
git add ...
git commit ...

Answer 5

Это имеет состав запроса функции. Чтобы убедиться в этом, присоединитесь к списку рассылки Git (git@vger.kernel.org) и немного прочтите его, чтобы получить представление о культуре. В то же время проясните свои мысли, подготовив документацию до / после, как было предложено выше.

Когда вы почувствуете себя готовым, представьтесь в списке и кратко объясните свою идею. Обязательно ответьте на вопрос о том, может ли эффект вашего предложения быть адекватно достигнут другими способами. Если вы получаете обнадеживающие слова, проследите за более подробной документацией. Получив отзыв о вашем предложении, вы можете решить продолжить отправку сообщения об ошибке в функции или оказаться в состоянии создать патч для рассмотрения.