Разрешите конфликты git rebase так же, как они были разрешены ранее

Я решил ретроспективно зафиксировать историю, которой никогда не было в Git, из другой старой системы контроля версий. Поэтому я создал потерянную ветку "newroot" и импортировал в нее коммиты из другой системы контроля версий. Следующий вопросВставить коммит перед корневым коммитом в Git?

Ветвь "newroot" закончилась файлами, точно совпадающими с корневым коммитом ветки "master".

Теперь я хочу переназначить ветку «master» на сиротскую ветку «newroot», например:

git rebase --onto newroot --root master

Проблема в том, что мне предлагают разрешить все конфликты слияния. Есть сотни слияний в течение многих лет. Я просто не могу решить их вручную. И в этом действительно нет необходимости, так как эти слияния уже были решены в прошлом. Поскольку rebase фактически не меняет содержимое (так как я перебираю идентичное дерево), я хочу, чтобы Git точно «воспроизвел слияние».

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

Я понял, что «rerere» может помочь здесь. Но мне бы пришлось включить его уже при первоначальном слиянии, верно? Или я могу ретроспективно воссоздать кэш "rerere"?

Я могу представить альтернативное решение моей задачи. Чтобы как-то попросить Git объединить ветки "newroot" и "master", без фактической перебазировки. Но я не уверен, что это возможно.

Ответы на вопрос(1)

Решение Вопроса

newroot" и "master", без фактической перебазировки. Но я не уверен, что это возможно.

Это называетсяточка пересадкис последующимfilter-branch для того, чтобы переписать историю мастера.
Увидетьэтот пост в качестве примера или жеэтот вопрос.

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

git rebase --merge -s recursive -X theirs --onto newroot --root master
 Martin Prikryl29 июн. 2016 г., 09:23
Хорошо, поэтому я добавляю точку пересадки, а затем, когда я вызываюfilter-branch, он видит точку пересадки и воссоздает историю в соответствии с точкой пересадки. После этого точка пересадки больше не нужна. Это верно?
 VonC29 июн. 2016 г., 09:19
@MartinPrikryl точка пересадки - это чисто локальная уловка, позволяющая сделать ветку родительской для другой ветви. Чтобы сделать этот трюк постоянным, требуется фильтр-ветвь, поскольку каждый SHA1 мастера должен отражать своего нового родителя, начиная с первого (который теперь будет иметь в качестве родителя старую импортированную ветвь). Сноваbugsquash.blogspot.fr/2010/03/stitching-git-histories.html показывает конкретный пример.
 Martin Prikryl29 июн. 2016 г., 09:17
Спасибо за Ваш ответ. Точка пересадки выглядит как решение, которое я искал. Можете ли вы объяснить, почемуfilter-branch нужен и что он делает в отношении точки пересадки?
 VonC29 июн. 2016 г., 09:36
@MartinPrikryl Да, как описано вbugsquash.blogspot.fr/2010/03/stitching-git-histories.html, Точка пересадки не понадобится после ответвления фильтра. Ветвь фильтра изменит историю, которую можно нажать. Точка пересадки является исключительно локальной для вашего репо и не будет выталкиваться никогда.

Ваш ответ на вопрос