українська мова ▾ Topics ▾ Latest version ▾ git-range-diff last updated in 2.48.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>…​]

ОПИС

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

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

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

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

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

  • <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>

Встановіть коефіцієнт витрати на створення/видалення на <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.

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

Цей прапорець передається програмі 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 може змінюватися. Він призначений для читання людиною у вигляді порцелянового виводу, а не для використання в різних версіях 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. У цьому режимі різниця різниць зберігатиме оригінальні кольори різниці та додаватиме перед рядками маркери -/+ з червоним або зеленим фоном, щоб було очевидніше, що вони описують, як сама різниця змінилася.

Алгоритм

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

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

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

Приклад: Нехай коміти 1--2 будуть першою ітерацією серії патчів, а A--C — другою ітерацією. Припустимо, що A — це вибірковий варіант 2, а C — вибірковий варіант 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]