В этом вопросе используется Git 2.7.0.windows.1, поэтому некоторые команды git могут быть устаревшими.
Если моя команда git merge не обнаруживает переименованный файл, как я могу указать git вручную объединить изменения в двух файлах, которые должны быть одним файлом, не запуская слияние заново и используя более низкий порог переименования?
Этапы воспроизведения:
git init
echo "//Hello world!" > hw.h
git add . && git commit -m "Initial commit"
git checkout -b someBranch
mv hw.h hw.hpp
echo "//Foobar" > hw.hpp
git add . && git commit -m "Change hw to HPP & change content"
git checkout master
echo "//Boofar" > hw.h
git add . && git commit -m "Change content of hw"
git merge -X rename-threshold=100% someBranch
Вы получите конфликты слияния, но не конфликтующие фрагменты. То есть единственный конфликт/ошибка, которую вы должны получить, это:
CONFLICT (modify/delete): hw.h deleted in branchB and modified in HEAD. Version HEAD of hw.h left in tree.
Automatic merge failed; fix conflicts and then commit the result.
И git status --porcelain покажет:
UD hw.h
A hw.hpp
Обычно при слиянии идеально установить порог обнаружения переименований, достаточно низкий, чтобы переименования обнаруживались. Некоторые люди рекомендуют 5%, например . В моем случае я выполняю массовое слияние (> 1000 файлов и около 9 млн LOC), и мне пришлось поднять порог переименования достаточно высоко, чтобы избежать любых «ложных срабатываний»; буквально на один процент ниже, и я получил огромное количество ложно обнаруженных переименований (я знаю, дублированный код — отстой). При значении, которое я использовал, я получаю лишь небольшое количество пропущенных переименований, что кажется лучшим вариантом.
TL;DR снижение порога переименования для меня не вариант; как я могу, не начиная слияние, сказать git считать hw.h и hw.hpp одним файлом (с конфликтами), а не двумя файлами, как показано выше?
