українська мова ▾ Topics ▾ Latest version ▾ git-range-diff last updated in 2.52.0

НАЗВА

git-range-diff — Порівняння двох діапазонів комітів (наприклад, двох версій гілки)

СИНОПСИС

git range-diff [--color=[<when>]] [--no-color] [<diff-options>]
	[--no-dual-color] [--creation-factor=<factor>]
	[--left-only | --right-only] [--diff-merges=<format>]
	[--remerge-diff]
	( <range1> <range2> | <rev1>…​<rev2> | <base> <rev1> <rev2> )
	[[--] <path>…​]

ОПИС

Ця команда показує відмінності між двома версіями серії латок, або, загалом, двома діапазонами комітів (ігноруючи коміти злиття).

За наявності аргументів <path> ці діапазони комітів відповідно обмежуються.

Для цього спочатку виявляються пари комітів з обох діапазонів, які відповідають одна одній. Два коміти вважаються відповідними, якщо різниця між їхніми латками (тобто інформацією про автора, повідомленням про коміт та різницею комітів) є досить незначною порівняно з розміром цих латок. Детальніше див. розділ «Алгоритм» нижче.

Нарешті, список комітів, які збігаються, відображається у порядку другого діапазону комітів, а коміти, що не збігаються, вставляються одразу після того, як будуть показані всі їхні попередники.

Існує три способи вказати діапазони комітів:

  • <range1> <range2>: Будь-який діапазон комітів може мати вигляд <base>..<rev>, <rev>^! або <rev>^-<n>. Див. ВИЗНАЧЕННЯ ДІАПАЗОНІВ у gitrevisions[7] для отримання додаткової інформації.

  • <rev1>...<rev2>. Це еквівалентно <rev2>..<rev1> <rev1>..<rev2>.

  • <base> <rev1> <rev2>: Це еквівалентно <base>..<rev1> <base>..<rev2>.

ОПЦІЇ

--no-dual-color

Коли різниці комітів відрізняються, git range-diff відтворює оригінальне забарвлення різниць та додає зовнішні маркери різниці -/+ з червоним/зеленим фоном, щоб було легше побачити, наприклад, коли відбулася зміна в доданих рядках.

Крім того, рядки різниці комітів, які присутні лише в першому діапазоні комітів, відображаються "сірим" (це можна змінити за допомогою налаштування конфігурації color.diff.<slot>, де <slot> є одним з contextDimmed, oldDimmed або newDimmed), а рядки різниці комітів, які присутні лише в другому діапазоні комітів, відображаються жирним шрифтом (це можна змінити за допомогою налаштувань конфігурації color.diff.<slot>, де <slot> є одним з contextBold, oldBold або newBold).

Це називається у range-diff "подвійним розфарбовуванням". Використовуйте --no-dual-color, щоб повернути розфарбовування всіх рядків відповідно до зовнішніх маркерів різниці (і повністю ігнорувати внутрішню різницю, коли справа доходить до кольору).

--creation-factor=<percent>

Встановлює коефіцієнт коригування витрат на створення/видалення на <відсоток>. Зазвичай встановлюється значення 60. Спробуйте вказати більше значення, якщо git range-diff помилково розцінює велику зміну як повне переписування (видалення одного коміту та додавання іншого), і менше значення — у зворотному випадку. Пояснення, чому це потрібно, див. у розділі «Алгоритм» нижче.

--left-only

Приховувати коміти, яких бракує в першому зазначеному діапазоні (або в "лівому діапазоні" при використанні формату <rev1>...<rev2>).

--right-only

Приховувати коміти, яких бракує в другому зазначеному діапазоні (або в "правильному діапазоні" при використанні формату <rev1>...<rev2>).

--diff-merges=<формат>

Замість того, щоб ігнорувати коміти злиття, згенеруйте для них різниці, використовуючи відповідний параметр --diff-merges=<формат> у git-log[1], та включіть їх у порівняння.

Примітка: У загальному випадку режим remerge буде найприроднішим для використання, оскільки він показує лише різницю (diff) поверх того, що створив би механізм злиття Git. Іншими словами, якщо коміт злиття є результатом git merge без конфліктів, режим remerge представить його порожньою різницею (diff).

--remerge-diff

Зручний параметр, еквівалентний --diff-merges=remerge.

--notes[=<ref>]
--no-notes

Цей прапорець передається програмі git log (див. git-log[1]), яка генерує латки.

<range1> <range2>

Порівняйте коміти, визначені двома діапазонами, де <range1> вважається старішою версією <range2>.

<rev1>…​<rev2>

Еквівалентно передачі <rev2>..<rev1> та <rev1>..<rev2>.

<base> <rev1> <rev2>

Еквівалентно передачі <base>..<rev1> та <base>..<rev2>. Зверніть увагу, що <base> не обовʼязково має бути точною точкою розгалуження гілок. Приклад: після перебазування гілки my-topic, git range-diff my-topic@{u} my-topic@{1} my-topic покаже відмінності, внесені перебазуванням.

git range-diff також приймає звичайні опції diff (див. git-diff[1]), зокрема опції --color=[<when>] та --no-color. Ці опції використовуються під час генерації "різниці між латками", тобто для порівняння автора, повідомлення коміту та різниці відповідних старих/нових комітів. Наразі немає можливості налаштувати більшість опцій diff, що передаються до git log під час генерації цих латок.

СТАБІЛЬНІСТЬ ВИВОДУ

Вивід команди range-diff може змінюватися. Він призначений для читання людиною у вигляді виводу porcelain, а не для використання в різних версіях Git для отримання текстово стабільного range-diff (на відміну від чогось на кшталт опції --stable для git-patch-id[1]). Також немає еквівалента git-apply[1] для range-diff, вивід не призначений для машинного читання.

Це особливо актуально під час передачі параметрів diff. Наразі деякі параметри, такі як --stat, можуть, як наслідок, створювати вивід, який є досить марним у контексті range-diff. Майбутні версії range-diff можуть навчитися інтерпретувати такі параметри специфічним для range-diff способом (наприклад, для --stat, що створює вивід, зрозумілий людиною, який підсумовує, як змінився diffstat).

КОНФІГУРАЦІЯ

Ця команда використовує налаштування diff.color.* та pager.range-diff (останнє є стандартно увімкненим). Див. git-config[1].

ПРИКЛАДИ

Якщо під час перебазування виникли конфлікти злиття, які потрібно розвʼязати, порівнювати зміни, внесені в результаті перебазування, одразу після цього за допомогою команди:

$ git range-diff @{u} @{1} @

Типовий вивід git range-diff виглядатиме так:

-:  ------- > 1:  0ddba11 Приготуйтеся до неминучого!
1: c0debee = 2: cab005e Додайте корисне повідомлення на початку
2: f00dbal ! 3: decafe1 Опишіть помилку
    @@ -1,3 +1,3 @@
     Author: A U Thor <author@example.com>

    -TODO: Опишіть помилку
    +Опишіть помилку
    @@ -324,5 +324,6
      Це очікувано.

    -+Несподівано, але програма також вилітає.
    ++Несподівано, але вона також вилітає. Це помилка, і поки що
    ++немає єдиної думки щодо того, як її найкраще виправити. Детальніше див. тікет #314.

      Contact
3:  bedead < -:  ------- TO-UNDO

У цьому прикладі є 3 старих та 3 нових коміти, де розробник видалив 3-й, додав новий перед першими двома та змінив повідомлення 2-го коміту, а також його diff.

Коли вивід надходить у термінал, він зазвичай має кольорове кодування, як і звичайний вивід git diff. Крім того, перший рядок (додавання коміту) зелений, останній рядок (видалення коміту) червоний, другий рядок (з ідеальним збігом) жовтий, як заголовок коміту виводу git show, а третій рядок забарвлює старий коміт червоним, новий зеленим, а решту — як заголовок коміту git show.

Однак простий порівняльний вивід з кольоровим маркуванням насправді трохи важко читати, оскільки він зафарбовує цілі рядки червоним або зеленим. Наприклад, рядок, у якому в старому коміті було додано «Що є несподіваним», повністю червоний, навіть якщо метою старого коміту було саме додавання чогось.

Щоб допомогти з цим, range стандартно використовує режим --dual-color. У цьому режимі різниця різниць зберігатиме оригінальні кольори різниці та додаватиме перед рядками маркери -/+ з червоним або зеленим фоном, щоб було очевидніше, що вони описують, як сама різниця змінилася.

Алгоритм

Загальна ідея така: ми генеруємо матрицю витрат між комітами в обох діапазонах комітів, а потім вирішуємо завдання з найменшою вартістю.

Матриця вартості заповнюється таким чином: для кожної пари комітів генеруються дві різниці, а також «різниця різниць» із трьома рядками контексту; потім кількість рядків у цій різниці використовується як вартість.

Щоб уникнути хибнопозитивних результатів (наприклад, коли латку було видалено, а неповʼязану латку було додано між двома ітераціями тієї ж серії латок), матриця витрат розширюється, щоб врахувати це, шляхом додавання записів з фіксованою вартістю для гуртових видалень/додавань.

Приклад: Нехай коміти 1--2 будуть першою ітерацією серії латок, а A--C — другою ітерацією. Припустимо, що A — це cherry-pick для 2, а C — cherry-pick для 1, але з невеликою модифікацією (скажімо, виправленою друкарською помилкою). Візуалізуємо коміти як двочастковий граф:

    1            A

    2            B

		 C

Ми шукаємо «найкраще» пояснення нового ряду з точки зору старого. Ми можемо представити «пояснення» як ребро графу:

    1            A
	       /
    2 --------'  B

		 C

Це пояснення надається «безкоштовно», оскільки змін не було. Аналогічно, C можна було б пояснити, використовуючи 1, але це має певну ціну c>0 через модифікацію:

    1 ----.      A
	  |    /
    2 ----+---'  B
	  |
	  `----- C
	  c>0

У математичних термінах ми шукаємо певний вид двочасткового зіставлення з мінімальною вартістю; 1 зіставляється з C за певну ціну тощо. Базовий граф насправді є повним двочастковим графом; вартість, яку ми повʼязуємо з кожним ребром, дорівнює розміру різниці між латками двох комітів. Щоб також пояснити нові коміти, ми вводимо фіктивні вузли з обох боків:

    1 ----.      A
	  |    /
    2 ----+---'  B
	  |
    o     `----- C
	  c>0
    o            o

    o            o

Вартість ребра o--C дорівнює розміру різниці C з поправкою, яка повинна бути меншою за 100%. Вартість ребра o--o дорівнює нулю. Коефіцієнт коригування необхідний, оскільки навіть якщо 1 і C не мають нічого спільного, вони все одно можуть мати кілька спільних порожніх рядків тощо, що може зробити присвоєння 1--C, o--o дещо дешевшим, ніж 1--o, o--C, навіть якщо 1 і C не мають нічого спільного. З коефіцієнтом коригування нам потрібна набагато більша спільна частина, щоб вважати патчі відповідними.

Загальний час, необхідний для обчислення цього алгоритму, дорівнює часу, необхідному для обчислення n+m різниць комітів, а потім n*m різниць латок, плюс час, необхідний для обчислення найменш витратного призначення між n та m різницями. Git використовує реалізацію алгоритму Йонкера-Вольгенанта для вирішення задачі призначення, яка має кубічну складність виконання. Знайдене зіставлення в цьому випадку виглядатиме так:

    1 ----.      A
	  |    /
    2 ----+---'  B
       .--+-----'
    o -'  `----- C
	  c>0
    o ---------- o

    o ---------- o

ДИВ. ТАКОЖ

git-log[1]

GIT

Частина набору git[1]