Вопрос по merge, git – Почему git не пытается объединить изменения в переименованные файлы?

18

Допустим, у меня есть файл, который

  1. Modified in master
  2. Modified in a feature branch
  3. Renamed in a feature branch

Когда я пытаюсь слиться из основного в ветвь функции, слияние завершается с

CONFLICT (modify/delete): X deleted in HEAD and modified in origin/master. Version origin/master of X left in tree.

Я понимаю, что существует конфликт, но почему он даже не пытается объединить изменения и поместить маркеры конфликта в файл?Предыдущие ответы, похоже, подразумевают, что так и должно быть. Все, что я получаю, - это две разные версии файла, где я должен выяснить разницу вручную и построчно менять порты от мастер-версии к моей версии.

Действия по воспроизведению:

git init
touch a
git add a
git commit -m 'initial import'

git checkout -b feature1
echo feature1 > a
git add a
git commit -m feature1
git mv a b
git commit -m feature1

git checkout master
echo bugfix > a
git add a
git commit -m bugfix

git checkout feature1 
git merge master 
Возможныйduplicate kostix

Ваш Ответ

1   ответ
31

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

Попробуйте объединить с: git merge master -s recursive -X rename-threshold=5%

@SeanAdkinson Поскольку стратегия слияния по умолчанию объединяет только конечные результаты, а не каждый коммит. Поэтому, если файл был изменен в другом коммите после переименования, он может больше не соответствовать пороговому значению, даже если это было ранее.
Обратите внимание, что% вrename-threshold это важно.
При первоначальной фиксации переименования, похоже, уже используется пороговое значение, поскольку переименованный файл может содержать незначительные различия. Есть идеи, почему бы не использовать тот же порог? Я ожидаю, так как он уловил переименование при первоначальном коммите, он должен поддерживать это при слиянии или перебазировании.

Похожие вопросы