Как `git rebase` пропускает коммит, который его изменение уже имеет в апстриме?

Question

git-rebase document говорит:

Если в ветке upstream уже содержится внесенное вами изменение (например, из-за того, что вы отправили патч, который был применен в апстриме),этот коммит будет пропущен.

Но как Git делает это?

Предположим, что любой коммит X является родителем коммита Y, а diffXY - результатиз git diff X Y команды.И у меня есть следующие коммиты:

o---o---o        <- master
 \
  o---o---o---o  <- test <- HEAD

Если я сделаю git rebase master.Затем, я думаю, Git делает пропущенный коммит уже в master, пропуская любой коммит Y в test, который diffXY уже имеет в master.

Я запустил несколько примеров, и онибыло похоже на то, что я догадался.

Это только мое предположение, я прав?

Плюс, Git выполняет эту задачу пропуска, прежде чем Git выполняет повторное применение test коммитов к master

Answer 1

Ответ VonC дает историю.Механизм - это то, что Git называет идентификатором патча .Концепция идентификатора патча в Git задокументирована (хотя и слегка) в git patch-id справочной странице , обобщив ее следующим образом:

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

Это то, что git rev-list --cherry-mark (с симметричной разностью ... запись) и git format-patch --ignore-if-in-upstream (с простой операцией исключения ..) делают для обнаружения дублирующих фиксаций.Если коммит, чей хеш по определению отличается от коммита (по крайней мере, потенциально) для копирования, имеет тот же ID патча , что и коммит, который будет скопирован, Git предполагает, что коммит уже скопирован и поэтомукопировать его не нужно.

Вы также спросили:

Кроме того, Git выполняет эту задачу пропуска, прежде чем Git выполняет повторное применение test коммитов к * 1028?*?

Да: список коммитов, которые должны быть скопированы, генерируется первым - во время которого патчи, эквивалентные идентификатору патча, отбрасываются вместе с всеми коммитами слияния, если вы нес использованием параметров -p или -r, после чего начинается процесс перебазирования.

(Если вы используете неавтоматизированный git rebase, использующий git am, процесс перебазирования по-прежнему использует вывод git format-patchв качестве входных данных для git am. В противном случае копируемые хеши коммитов сохраняются в файле или в секвенсоре, который может сохранять или не сохранять их в файле, а затем коммиты выбираются вишней либо с помощью команды git cherry-pickили прямойтолько секвенсором.Детали зависят от вашего винтажного Git.)

Answer 2

первые версии git rebase (1.4.4, октябрь 2006 г.) использовали git format --ignore-if-in-upstream

При этом будут проверены все исправлениядостижимы с <since>, но не с <until> и сравнивают их с генерируемыми патчами, а любой соответствующий патч игнорируется.

Так что он смотрел на патч ids : См. commit 9c6efa3 для реализации .

 if (ignore_if_in_upstream &&
    !get_patch_id(commit, &patch_id_opts, sha1) &&
     lookup_object(sha1))
     continue;

"Идентификатор патча" - это не что иное, как суммаSHA-1 файловых различий, связанных с патчем, с пропущенными пробелами и номерами строк.
Как таковой, он «достаточно стабилен», но в то же время также достаточно уникален, т. Е. Два патча с одинаковым «патчем».ID "почти гарантированно будет одним и тем же.

Это было позже делегировано git rebase-am (Git 1.7.6, февраль 2011)

И commit b6266dc, Git 2.1.0, июль 2014 использовал --cherry-pick вместо --ignore-if-in-upstream

При использовании git format-patch --ignore-if-in-upstream нам разрешено толькоve единственный диапазон ревизий.
В следующем коммите мы захотим добавить дополнительную исключающую ревизию для правильной обработки точек разветвления, поэтому преобразуйте git-rebase--am, чтобы использовать симметричную разность с --cherry-pick --right-only.

( Усовершенствовано в Git 2.18 )

Это не меняет механизм "пропустить идентичную фиксацию".