Какой порядок `git rebase` использует для выбора коммитов из объединенной ветви?

Question

Предположим, у нас есть:

C1--C2--C3--C6--C7   <- topic, HEAD
 \   \     /
  \  C4--C5      
   \
    C8--C9           <- master

(мы добавили пустое file1 и зафиксировали в C1, добавили пустое file2 и зафиксировали в C2 и т. Д.).

Затем мы делаем:

$ git rebase master

Результат:

C1--C8--C9                         <- master
         \
         C4'--C2'--C5'--C3'--C7'   <- topic, HEAD

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

Как я узнал из главы 3.6 в книге git-scm.com , Git пропустил C6, который является результатом слияния, поэтому C6' нездесь.

У меня вопрос, какой порядок использования Git для вишни из ветки topic?Почему результат равен ...-C4'--C2'--C5'--C3'--C7' вместо ...-C2'--C3'--C4'--C5'--C7' (в порядке времени)?

Answer 1

(Кстати, спасибо за сценарий репродуктора - он был чрезвычайно полезен здесь.)

Порядок изменился в прошлом, но в целом он генерируется при запуске git rev-list (сестринская командаgit log, который по умолчанию выдает только хэш-идентификаторы).Поскольку хэш-идентификаторы трудны для людей, обычно проще использовать git log, чтобы увидеть порядок.

В этом случае порядок был следующим:

$ git log --oneline --reverse --no-merges master..topic
5ff52aa C4
aefbb19 C2
0363c27 C5
90aaf5d C3
f953082 (topic) C7

Однако, если мы добавим --topo-order, который git rebase делал в различных более старых версиях Git, мы получаем:

$ git log --oneline --reverse --topo-order --no-merges master..topic
aefbb19 C2
90aaf5d C3
5ff52aa C4
0363c27 C5
f953082 (topic) C7

Фактический порядок основан на отметках времени коммита в случае, когда на выбор доступно более одного активного коммита.То есть Git выполняет ревизионную прогулку, начиная с tip commit назад.Всякий раз, когда происходит слияние, Git помещает всех родителей в очередь приоритетов, увеличивая количество посещений коммитов.Порядок сортировки по умолчанию для приоритетной очереди основан на отметке времени коммиттера.Так как git rebase не устанавливает никаких других приоритетов, это тот, который используется.

(Порядок new-ish, не отсортированный по топологии является результатом внутренней команды new-ish git rebase--helper, впервые появившаяся в Git версии 2.13. Слияние, «сохраняющее» - действительно воссоздающее, - вариант git rebase -p по-прежнему использует топологическую сортировку. Причудливая новая метка git rebase -r не требует топосортировки.)