Родительский номер основной линии при фиксации слияния при выборе вишни

Мое понимание, основанное на этом ответе, заключается в том, что родительский элемент 1 – это объединяемая ветвь, а родительский 2 – объединяемая ветвь. Итак, в вашем случае родитель 1 - это A, а родитель 2 - B. Поскольку вишневый выбор действительно применяет разницу между двумя коммитами, вы используете -m 1 для применения только изменений из B (поскольку разница между A и C содержит изменения из B). В вашем случае это, вероятно, не имеет значения, так как у вас нет коммитов между A и C.

Так что да, -m 1 — это то, что вам нужно, и это верно, даже если между A и C были дополнительные коммиты.

Если вы хотите, чтобы новая история немного больше походила на исходную, есть еще один способ сделать это:

git cherry-pick B
git checkout Z
git merge --no-ff --no-commit B
git commit --author="Some Dev <[email protected]>" --date="<commit C author date>"

(При необходимости вы можете создать новую ветку для B перед сбором вишен.)

Это сохранит информацию об авторе и даст вам историю, которая выглядит следующим образом:

    B'
   /  \
  Z -- C'
 /
A -- C -- D
 \  /      
  B

Я проголосовал за ответ Скотта Велдона, что правильно, но я просто хочу добавить попытку рисования ASCII, включающего родительский нумерация. Дан график, который выглядит следующим образом:

       B
      / \
...--A   D--...
      \ /
       C

мы можем сказать, что узел D является фиксацией слияния, но мы не можем сказать, является ли узел B или C первым родителем узла D. Один из двух обязательно является первым родителем, а другой - вторым. Поэтому, если нам нужно знать, мы должны пометить рисунок, что занимает больше места. Вот одна из таких попыток.

         B
       /   \²
...--A       D--...
       \   /¹
         C

Теперь мы видим, что по какой-то причине¹ я нарисовал график «вверх ногами»: этот коммит C на самом деле является первым родителем D, а коммит B — вторым родителем.

Можно создавать произвольные слияния с помощью команд более низкого уровня («сантехника»). В частности, git commit-tree просто принимает столько -p аргументов, сколько вы хотите ему передать, в том порядке, в котором вы их даете, и создает новую фиксацию с данными фиксациями в качестве родительских. Дайте ему один -p, и он сделает обычную фиксацию с одним родителем. Не дайте ему -p аргументов, и он сделает корневую фиксацию. Дайте ему 155 различных -p аргументов (все должны, конечно, разрешаться в действительные идентификаторы коммитов), и он сделает один массовый коммит слияния осьминога.

Однако команда git merge всегда делает новую фиксацию с первым родителем, являющимся текущим HEAD (отсюда и текущая ветвь, если она находится на ветке). Второй родитель для стандартного слияния с двумя родителями происходит от .git/MERGE_HEAD, в который git merge записывает другой идентификатор коммита. Если слияние конфликтует или окончательная фиксация слияния задерживается на --no-commit, этот MERGE_HEAD файл фактически является единственным местом, где доступен идентификатор фиксации.

(Когда git merge выполняет слияние осьминога, используя стратегию -s octopus — эта стратегия принудительно используется для таких слияний — и несколько дополнительных родителей, она прерывается и вообще не оставляет следов, если есть конфликты слияния, поэтому случай конфликта никогда не возникает. У меня есть не пробовал комбинировать --no-commit со слиянием осьминога, но это, по логике, оставило бы родителей со 2-го по N-й в MERGE_HEAD, если Git вообще это позволяет.)

¹Упрямство.