Могу ли я представить git rebase как набор вишен?

Кажется, что «git rebase» имеет дополнительную резервную логику для обработки сбоев слияния:

Falling back to patching base and 3-way merge...

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

Вероятно, правильное решение — просто не пытаться представить перебазирование как серию выборок, но было бы неплохо, если бы это было возможно, поскольку тогда я могу иметь дело как с перебазированием, так и с произвольным набором изменений, используя один и тот же поток.


person Christian Goetze    schedule 13.05.2019    source источник
comment
Можете ли вы уточнить, что вы пытаетесь сделать? График может помочь.   -  person EncryptedWatermelon    schedule 13.05.2019
comment
У меня есть рабочий процесс CI, который может либо использовать перебазирование, либо набор разрозненных исправлений. Вместо того, чтобы различать два случая, я бы предпочел преобразовать перебазирование в набор вишен и не думать при оформлении заказа.   -  person Christian Goetze    schedule 14.05.2019


Ответы (1)


Большинство команд git rebase на самом деле делают запуск git cherry-pick.

Запасной вариант, который вы видите, происходит от одной формы git rebase, которая по историческим причинам не использует git cherry-pick. Эта форма используется, когда вы вызываете не-интерактивный git-rebase и не используете какие-либо параметры, которые заставляют его использовать новый и улучшенный метод вызова перебазирования.

Старая форма обычно производит тот же эффект. Он состоит из использования git format-patch для превращения каждой фиксации в патч, а затем использования git am --3way для применения всех отформатированных патчей. Опция --3way сообщает git am, что если патч нельзя применить вслепую, он должен использовать index строк в каждом отформатированном патче, чтобы выполнить часть того, что git cherry-pick выполнил бы автоматически.

Если вы хотите, чтобы rebase использовала git cherry-pick напрямую, вы можете:

  • укажите опцию -k или
  • укажите опцию -m или
  • укажите опцию -s strategy или
  • укажите опцию -X extended-option или
  • использовать интерактивную перебазировку (-i или --interactive) или
  • используйте опцию --autosquash или
  • используйте параметр -p или (Git 2.18+) -r.
person torek    schedule 13.05.2019
comment
Я бы предпочел понять, как я могу заставить свою серию патчей вести себя как перебазирование. Я думаю, вы дали ответ, но мне нужно его закодировать и протестировать. Если я правильно понимаю, каждый выбор вишни должен использовать формат-патч и git am --3way. - person Christian Goetze; 14.05.2019
comment
Я думаю, что я пытаюсь сказать, что я пытался применять выборки вишни один за другим, и это терпит неудачу, но перебазирование проходит успешно... но вы, кажется, говорите, что это должно было быть успешным... - person Christian Goetze; 14.05.2019
comment
Я не уверен, что ваш вопрос тогда. Если у вас есть серия патчей, используйте git am --3way (или -3 для краткости), чтобы получить тот же эффект, что и git rebase при использовании git format-patch и git am. Обратите внимание, что если вы не управляете операцией git format-patch, вы получите сокращенные index строки, которые могут оказаться бесполезными. Вы хотите, чтобы тот, кто создает патчи, использовал --full-index. Или, если у вас есть ряд хэш-идентификаторов коммитов в вашем собственном репозитории, используйте git cherry-pick для них по одному, чтобы применить их к текущему HEAD. - person torek; 14.05.2019
comment
Использование cherry-pick в некоторых отношениях лучше, но также и медленнее (поскольку для поиска переименований выполняется сравнение всего дерева). Также обратите внимание, что перебазирование заканчивается принудительным перемещением метки ветки на вновь созданные коммиты; если вы сами вызываете git cherry-pick или git am / git apply, вы должны сделать это тоже сами. - person torek; 14.05.2019
comment
Осталось учесть, что когда git rebase перечисляет коммиты для git cherry-pick (используя путь выбора кода), он опускает некоторые коммиты намеренно. В частности, коммиты, которые существуют как в восходящей, так и в текущей ветке, и имеют одинаковый идентификатор исправления в обеих сторонах, опускаются; все слияния опускаются, если только не используются -p или -r, и в этом случае они специально перечисляются, чтобы их можно было повторить. Перечисление использует git rev-list --left-right --cherry-mark <upstream>...HEAD, чтобы выяснить, какие коммиты есть какие. - person torek; 14.05.2019
comment
(Вышеупомянутые детали не на 100% точны, иногда есть --no-merges, а иногда вам может сойти с рук --right-only. До недавних изменений, чтобы сделать git rebase весь код C, было легче определить, какие операции перебазирования выполнялись и какую git rev-list команду они использовали, как и все несколько очень больших сценариев оболочки.) - person torek; 14.05.2019