Git log -p -- <файл> показывает коммит без патча
Я попросил git показать мне все коммиты, которые изменили определенный файл, и он выдал то, что я просил, за исключением того, что некоторые коммиты не показывают никаких изменений в указанном файле (и вместо этого появляется только хеш коммита/автор/сообщение и т. д.). Кажется, что большинство этих коммитов представляют собой слияния. Какой в этом может быть смысл?
Команда: git log -p -- <path/to/file>
commit <hashM>
Merge: <hash1> <hash2>
Author: Name <Email>
Date: <Date>
Merged with develop.
commit <hashC>
Author: <Name> <Email>
Date: <Date>
Modified file to add new header.
diff --git a/<path/to/file.cpp> b/<path/to/file.cpp>
index ece9ea6fc..370c23a50 100644
--- a/<path/to/file.cpp>
+++ b/<path/to/file.cpp>
@@ -1,6 +1,12 @@
#include "Header.h"
+#include "NewHeader.h"
#include "StandardHeader.h"
#include "OtherHeader.h"
Этот коммит hashM мне кажется странным, потому что он появляется как результат выполнения команды, но не показывает никаких изменений в файле. hashC с другой стороны, это не странно: в файле есть изменения.
О, это было бы действительно здорово! Это означает, что Git знает, как отличить изменения, вызванные автоматическим объединением (я использую KDiff3), от изменений, внесенных вручную! Различает ли он также полуавтоматическое разрешение конфликтов (например, выбор версии A вручную без внесения каких-либо фактических изменений вручную) и полностью автоматическое разрешение конфликтов (автоматический первый проход KDIff)? Кроме того, могу ли я использовать это, чтобы указать git показывать мне только ручные изменения в списке коммитов, включая слияния? При необходимости я могу составить из них другой вопрос. Сначала мне нужно подтверждение правильности вашего анализа.
Ответы 1
По умолчанию git log не показывает различия при слияниях, он думает, что вы пытаетесь найти источник какого-то изменения, а не слияния (возможно, довольно многочисленные), которые только что его распространили.
Но желание получить эти различия достаточно распространено, для этого есть флаг, короткий вариант: git log -m будет выполнять различия против последующих родительских слияний, поэтому, например, если вы хотите временно рассматривать все слияния как сквош-слияния, вы можете сделать git log -m --first-parent.
Хорошо, спасибо. Уточнение: «git log -m будет выполнять различия с последующими родителями слияния» в каком смысле я говорю git log следовать за конкретным родителем, если не предоставляется никакой другой вариант, кроме -m (и -p, конечно)? Будет ли он показывать разницу со всеми родителями? Кажется, да, после попытки.
И что тогда такое сквош-слияние в этом контексте? Если я ограничу исследование git log первым родителем, не проигнорирую ли я изменения, поступающие из других ветвей? Я попробовал, вроде так и есть. Разница коммита слияния с его единственным родителем будет такой же, как комбинированные различия коммита слияния с каждым из его родителей. Здесь с помощью --first-parent я просто получаю частичную разницу коммитов слияния с их первым родителем. Для меня ничего мягкого.
@Чарльз, ваш первый, посмотрите упрощение истории в документации git log, повторите второй: у вас все наоборот, различия между слиянием и его первым родителем - это именно те изменения, которые вносятся при слиянии второго родителя.
Коммиты слияния (по моему опыту) будут отображать изменения в файле только в том случае, если в этом коммите происходит ручное вмешательство в файл (например, помимо прочего, конфликт).... поэтому я думаю, это правильно, что вы получил этот коммит, потому что, вероятно, есть изменения из обеих ветвей этого файла.