Как вывести список разрешенных конфликтов в коммите слияния?
При слиянии ветки может возникнуть конфликт, который мы должны решить, чтобы завершить слияние. Как мы можем перечислить ТОЛЬКО статистику разрешенных конфликтов при слиянии?
1 ответ
TL;DR ответ: просто попробуй.
В git ветви имеют нулевую стоимость, поэтому просто создайте пару test_merge_source а также test_merge_destination ветви и начать слияние. Через 5-10 минут вы либо закончите, либо у вас останется немного / немного / много, потому что произошло несколько / несколько / много конфликтов, и вы можете завершить / отменить попытку объединения.
Извините, что даю вам отрицательный ответ, но предпосылка для вашего вопроса в корне неверна, и то, что вы просите, невозможно.
Потому что для любого компьютерного алгоритма невозможно определить, является ли что-то конфликтом или нет. Да, есть инструменты, которые автоматизируют слияние разных файлов, но даже идеальное и беспроблемное слияние может все же привести к конфликту.
Вопрос находится в том же диапазоне, что и вопрос о количестве строк, которые меняются между версиями, на который также невозможно ответить.
/* example1.c */
#include <stdio.h>
-#include <varargs.h>
+#include <stdarg.h>
...
/* In this diff one line is changed */
/* example2.c */
#include <stdio.h>
-#include <varargs.h>
+#include <math.h>
...
/* In this diff one line is removed and one line added */
Как показано выше, если строка изменена или нет, полностью зависит от контекста. Поэтому ни один (вменяемый) инструмент контроля версий никогда не попытается сказать вам, сколько строк было изменено, они только говорят, что строки добавлены / удалены.
Теперь вы можете сказать, что вас интересуют неудачные автоматические слияния, а не конфликты. Справедливо, но это полностью зависит от используемого инструмента. Внутренняя обработка слияния в Git, например, потерпит неудачу, если две строки рядом друг с другом будут изменены, а KDiff3 - нет (как правило, это то, что вам нужно, но существует более высокий риск того, что это неверно, чем для строк, расположенных дальше друг от друга, поэтому существует компромисс).
Это означает, что то, что автоматически объединяется, не является статичным и может со временем меняться. Итак, вы ищете то, что не было автоматически объединено с версией git, использованной при первоначальном объединении кода, или каков будет результат нового слияния с сегодняшним git?1
Существует команда gre rerere, которая записывает разрешенные неудачные попытки слияния, которые, возможно, могут быть использованы для извлечения такой информации. Но он должен быть явно включен, он значительно меняет обработку слияния, это только настройка для каждого репозитория, он хранит историю только в течение ограниченного времени и может быть очищен, так что это далеко не падение в решении.
1 Ответ на этот вопрос на самом деле просто попробуйте, как указано в начале.