Как мне ограничить диапазон коммитов, о которых сообщает git log?

Question

Я пытаюсь проверить, какие ветви были объединены в источник между двумя коммитами с чем-то по следующим строкам:

git log --merges --first-parent --oneline origin 7284b1a6dea454c2023efb709a31ee9dbcde8de6..79764fa47dde40ed8aecf203a606e64409e3f895

Где 7284b1a6dea454c2023efb709a31ee9dbcde8de6 было совершено ранее, чем 79764fa47dde40ed8aecf203a606e64409e3f895 в истории origin.

По какой-то причине он возвращает все на свои места, а не ограничивает диапазон коммитов между этими двумя SHA.

Документы предполагают, что следует ограничить его диапазоном:

Показывать только коммиты в указанном диапазоне ревизий. Когда <revision range> не указано, по умолчанию используется HEAD (т. Е. Вся история, ведущая к текущей фиксации). origin..HEAD определяет все коммиты, достижимые из текущего коммита (т.е. HEAD), но не из источника. Полный список способов написания заклинаний см. В разделе «Задание диапазонов» в gitrevisions [7].

Подробнее здесь :

Операция set ^ r1 r2 появляется так часто, что для нее есть сокращение. Если у вас есть два коммита r1 и r2 (названные в соответствии с синтаксисом, описанным в разделе «УКАЗАНИЯ ПЕРЕСМОТРА» выше), вы можете запросить коммиты, которые достижимы из r2, за исключением тех, которые достижимы из r1 с помощью ^ r1 r2, и его можно записать как r1. .R2.

Что я делаю не так? Как предотвратить слияние списков, которое произошло между 79764fa47dde40ed8aecf203a606e64409e3f8 и HEAD?

[Изменить]

Для ясности история выглядит примерно так ...

  o   HEAD
  |  
  o  
  |  
  o   79764fa47dde40ed8aecf203a606e64409e3f895
  | 
  o 
  | 
  o 
  | 
  o 
  | 
  o 
  | 
  o   7284b1a6dea454c2023efb709a31ee9dbcde8de6
  | 

Answer 1

Я пытаюсь проверить, какие ветви были объединены в источник между двумя коммитами [...] Что я делаю не так?

Вы указываете origin в качестве подсказки. Вы указали основание и верхушку диапазона, который вам действительно нужен, с помощью 7284b1a6..79764fa4, (любые заклинания, которые разрешают эти два коммита, будут делать), git log не нужно искать удаленные URL и тому подобное, поэтому он не проверяет для удаленного имени он просто разрешает все для фиксации идентификаторов.

Answer 2

Попробуйте использовать опцию "--graph" в дополнение к тем, которые вы уже включили:

git log --graph --merges --first-parent --oneline origin 7284b1a6dea454c2023efb709a31ee9dbcde8de6..79764fa47dde40ed8aecf203a606e64409e3f895

( РЕДАКТИРОВАТЬ : на самом деле, с --first-parent, он не должен показывать больше информации).

Прежде всего, это зависит от того, где сейчас находится ваша ГОЛОВА. Тот факт, что ваш журнал возвращается в HEAD, может быть совпадением. HEAD фактически указывает на последнюю вещь, которую вы отметили git checkout.

Кроме того, git log a..b (на самом деле log или любая другая команда) возвращает "все, что достижимо из b , и что не достижимо из a ». Это означает, что если ваша история выглядит примерно так:

  o     o b
  |     |
a o     o
  |     |
  o     o
  |     |
  o     o
  |     |
  o     o
  |     |
  o     o
  |     |
  o     o
   \   /
    \ /
     o
     |
     o
     |
     o
     |
     o

Тогда git log a..b фактически даст вам все 7 коммитов в правой ветви после точки слияния. Хронологическая временная метка здесь не имеет значения, что сначала неясно, потому что без какой-либо опции журнал будет отображать свой фиксированный набор в виде плоского списка.