конфликты git rebase, как удалить все конфликтующие файлы, которые были удалены в HEAD

Question

В некотором контексте я пытаюсь перебазировать свою ветку от мастера.Но в master были внесены некоторые изменения, которые удаляют большую часть базы кода (это нормально, и об этом ожидали и говорили).Теперь я перебрасываю свои изменения с главного, но получаю безумное количество конфликтов файлов, которые говорят: CONFLICT (modify/delete): someFile.fileType deleted in HEAD and modified in added commitName. Version added commitName of someFile.fileType left in tree. Хорошо делать что-то вручную для примерно 10 файлов, но у меня более 1000 таких файлов.Как я могу git rm эти файлы и продолжить ребазинг?

Дополнительная информация: Я выполнил следующую команду git rebase master

Answer 1

Массовая обратная обработка всего, что угодно - это задание для git filter-branch.

git diff --name-only --diff-filter=D  ...master

создаст список всех файлов, которые были удалены с мастера с момента вашего перехода.

wipelist=`mktemp`
git checkout -b WIP
git diff  --name-only  --diff-filter=D   ...master    >$wipelist
git filter-branch --prune-empty --index-filter "
                git update-index --force-remove --stdin  <$wipelist
        " -- master..

Теперь у вас есть ветвь WIP, которая в точности соответствует тому, что было извлечено ранее, за исключением того, что на ней нет файлов, которых больше нет в главной ветке, самый первый коммит на WIP удаляет все впоследствии удаленныена master.

Answer 2

Метод достаточно прост, но приложение этого метода требует некоторой осторожности, поскольку он может легко привести к ужасным результатам.Что вам нужно сделать, это определить, какие файлы существуют на какой стадии (ях) в индексе, а затем соответствующим образом обновить индекс.

Как вы сказали, у вас есть:

CONFLICT (modify/delete): someFile.fileType deleted in HEAD and modified in ...

Следовательно, у вас будет файл, который существует в base коммите (на этапе 1 в индексе) и существует в прочем коммите (этап 3 в индексе), но нев коммите HEAD (этап 2 в индексе).Этот файл также будет существовать в рабочем дереве .

Чтобы выяснить, какие файлы находятся в индексе, на каких этапах запустите git ls-files --stage.Затем вам нужно изменить содержимое индекса, чтобы разрешить любые конфликты и определить, что будет зафиксировано.Если вы хотите разрешить этот конфликт путем удаления файла в окончательной фиксации, вы можете просто запустить git rm someFile.fileType, который удалит все записи индекса и версии рабочего деревафайла также.

Следовательно, как очень хитрый метод, этот может работать:

git ls-files --stage | awk $'/ 3\t/ { print $4 }' | xargs git rm

Be очень осторожныйс этим!Если вы слепо примените какой-то рецепт, который вы не понимаете, вы можете испечь ядовитый пирог.Обратите внимание, что это полностью игнорирует, имеет ли тот же файл запись этапа 2, и ищет только запись этапа 3 в индексе.Он также ведет себя неправильно для любого пути, в котором есть пробел, поскольку awk здесь разделяет поля пробелами.

Обратите внимание, что все файлы разрешенные находятся в индексе как нулевая ступень,поэтому, если у вас есть какие-либо конфликты, кроме изменений / удаления, вы можете сначала разрешить их вручную, а затем использовать приведенную выше команду для git rm оставшихся.