Я пытаюсь получить все хеши коммитов, которые приходят от слияния.
Если вы контролируете, выполняется ли слияние, у вас идеальная ситуацияпотому что вы можете легко перечислить коммиты, которые будут доступны после слияния, которые в данный момент недоступны до начала слияния. (Поскольку слияние не изменяет более раннюю часть графика, вы все равно можете получить тот же результат после слияния.)
Допустим, вы находитесь на коммите, хэш которого равен H на кончикеответвление mainline, и вы собираетесь - но еще не выполнили команду:
git merge feature
для ввода коммитов из feature, которые еще не из mainline, как в:
...--o--*--o--o--H <-- mainline
\
E--F----G <-- feature
Список коммитов, которые должно принести это слияние - что на самом деле не так интересно, как меняет , что оно будет слито, поскольку возможно, например, что Fпросто прямой возврат E, так что только фиксация G действительно имеет значение - это просто те, которые перечислены:
git log mainline..feature
Вы можете захотеть контролировать порядок перечисления. См. Ниже, после следующего бита в кавычках.
Обратите внимание, что после слияния, у вас есть:
...--o--*--o--o--H--M <-- mainline
\ /
E--F----G <-- feature
, и введенные коммиты - это те, которые перечисленыM^1..M^2. (Это предполагает простое слияние с двумя концами, которое приводит к истинной фиксации слияния. Слияния осьминога перечислимы, но требуют более сложного синтаксиса, а слияния быстрой перемотки не записывают предыдущий совет mainline и проблематичны для анализа послефакт.)
Один из подходов, которые я пробовал, - это нахождение коммитов между коммитом слияния и последним коммитом, добавленным к мастеру. Однако, по-видимому, они, похоже, связаны временными метками.
Команда git log просматривает график фиксации, используя очередь с приоритетами. Ваше наблюдение за "сеткой по меткам времени" связано с приоритетом элементов в очереди. Вы можете просто захотеть контролировать этот приоритет, возможно, с помощью --topo-order.
Общий цикл структурирован следующим образом:
Все вставки подчиняютсяОтрицания командной строки, например, --not foo исключают все коммиты, достижимые из коммита, указанного foo, включая сам коммит foo. (Это влияет как на инициализацию в следующей точке, так и на итерацию ниже.)
git log инициализирует очередь, вставляя в качестве начальных точек все коммиты, упомянутые непосредственно / положительно в команделиния. Если коммиты не упомянуты, введите HEAD. («Положительно» здесь относится к факту, что B ^A имеет положительную ссылку на B и отрицательную ссылку на A. Таким образом, A..B исключает коммиты, достижимые из A, так же, как --not A. )
Теперь, когда очередь не пуста, git log запускается:
- Удаляет передний коммит из очереди и работает с ним.
- Вставьте в очередь любого родителя (ей) этого коммита, измененного любым выбранным Упрощением истории или другими параметрами (включая переписывание родителя), которых нет в очереди и которые еще не посещены.
Общий процесс завершается, когда очередь пуста.
Учитывая, что слияние имеет - по определению - две или более родительских фиксации, любой шаг git log, который traverses объединение может вставить в очередь два или более коммитов. Конечно, очередь также может начинать с двумя или более коммитами в ней. Всякий раз, когда в очереди есть два или более коммитов, именно приоритет определяет, какой коммит находится в какой позиции в очереди.
Приоритет по умолчанию определяется датой коммиттера. с более высокими значениями (более поздними датами), перемещающимися в начало очереди. Однако:
--date-order обеспечивает, чтобы дети опережали родителей. В противном случае он совпадает со значением по умолчанию.
--author-date-order использует дату автора вместо даты коммиттера и в остальном совпадает с --date-order (родители выходят после всех их потомков).
--topo-order избегает чередования ветвей слияний.
См. документацию git log для получения подробной информации. Обратите внимание, что --graph подразумевает --topo-order.