Jump to content

diff

This is a fully translated article. Click here for more information.
From DawoumWiki, the free Mathematics self-learning

diff
Original author(s)Douglas McIlroy
(AT&T Bell Laboratories)
Developer(s)Various open-source and commercial developers
Initial releaseJune 1974; 50 years ago (1974-06)
Operating systemUnix, Unix-like, V, Plan 9, Inferno
PlatformCross-platform
TypeCommand

컴퓨팅에서, 유틸리티 diff는 파일 내용 사이의 차이를 계산하고 표시하는 데이터 비교 도구입니다. 다른 목적을 위해 사용되는 편집 거리 개념과 달리, diff는 문자 중심이 아니라 줄-중심이지만, 다른 파일에서 하나의 파일을 만들기 위해 가장 작은 삭제와 삽입 집합을 결정하려고 시도한다는 점에서 Levenshtein distance와 비슷합니다. 그 유틸리티는 사람 또는 컴퓨터가 모두 변경 사항을 구문 분석하고, 패치에 사용할 수 있도록 여러 표준 형식 중 하나로 변경 사항을 표시합니다.

전형적으로, diff는 같은 파일의 두 버전 사이의 변경 사항을 표시하기 위해 사용됩니다. 최신 구현은 역시 바이너리 파일도 지원합니다.[1] 출력은 유닉스 프로그램 패치와 함께 적용될 수 있기 때문에, "diff" 또는 패치라고 합니다. 유사한 파일 비교 유틸리티의 출력은 역시 "diff"라고 불립니다; 검색 행위를 설명하기 위해 "grep"이라는 단어를 사용하는 것처럼, 단어 diff는 데이터 차이와 그 결과를 계산하는 일반적인 용어가 되었습니다.[2] POSIX 표준은 "diff" 및 "patch" 유틸리티의 동작과 해당 파일 형식을 지정합니다.[3]

History

diff는 1970년대 초 뉴저지 머레이 힐에 있는 벨 연구소에서 등장한 유닉스 운영 시스템에서 개발되었습니다. 첫 번째 출시된 버전은 1974년 버전 5 유닉스와 함께 제공되었고,[citation needed] Douglas McIlroyJames Hunt에 의해 작성되었습니다. 이 연구는 diff의 초기 프로토타입을 개발한 James W. Hunt와 공동으로 작성한 1976년 논문에 발표되었습니다.[4] 이 논문에서 설명한 알고리듬은 Hunt-Szymanski 알고리듬으로 알려졌습니다.

McIlroy의 연구는 GECOS에 대한 Steve Johnson의 비교 프로그램과 Mike Leskproof 프로그램에 선행되고 영향을 받았습니다. Proof는 역시 유닉스에서 시작되었고, diff와 마찬가지로, 줄 단위 변경을 생성했었고 프로그램 출력에서 줄 삽입과 삭제를 표시하기 위해 꺾쇠-괄호 (">" 및 "<")도 사용했습니다. 이들 초기 응용 프로그램에 사용된 휴리스틱은, 어쨌든, 신뢰할 수 없는 것으로 여겨졌었습니다. diff 도구의 잠재적인 유용성은 McIlroy로 하여금 다양한 작업에 사용할 수 있지만 PDP-11 하드웨어의 처리와 크기 제한에서 잘 수행되는 보다 강력한 도구를 연구하고 설계하게 했습니다. 문제에 대한 그의 접근 방식은 Alfred Aho, Elliot Pinson, Jeffrey Ullman, 및 Harold S. Stone을 포함한 벨 연구소에서 개인과도 협력한 결과였습니다.

유닉스의 맥락에서, ed 줄 편집기의 사용은 diff에 기계에서 사용할 수 있는 "편집 스크립트"를 생성할 수 있는 자연스러운 기능을 제공했습니다. 이들 편집 스크립트는, 파일에 저장될 때, 원본 파일과 함께 ed에 의해 수정된 파일 전체로 재구성될 수 있습니다. 이것은 파일의 여러 버전을 유지 관리하기 위해 필요한 보조 저장소를 크게 줄였습니다. McIlroy는 다양한 출력 형식이 설계되고 구현될 수 있는 diff에 대해 후처리기를 작성하는 것을 고려했지만, diffed 명령에서 허용되는 구문과 역순 입력을 생성하는 책임을 지도록 하는 것이 더 검소하고 간단하다는 것을 발견했습니다.

1984년 후반에 Larry Wall은 별도의 유틸리티, 패치를 만들었고, mod.sourcesnet.sources 뉴스 그룹에 소스 코드를 공개했습니다.[5][6][7] 이 프로그램은 diff에서 출력으로 파일을 수정하는 기능을 일반화하고 확장했습니다.

Emacs에서 모드는 역시 패치 형식을 변환하고 심지어 대화식으로 패치를 편집할 수는 것을 허용합니다.

diff의 초기 년도에서, 소프트웨어 코드와 기술 문서 마크업의 변경 사항 비교, 프로그램 디버깅 출력 확인, 파일 시스템 목록 비교 및 컴퓨터 어셈블리 코드 분석이 일반적인 용도로 사용되었습니다. ed를 대상으로 한 출력은 파일에 대한 일련의 수정 사항에 대한 압축을 제공하도록 동기를 부여했습니다. 소스 코드 제어 시스템 (SCCS)과 수정본을 보관하는 기능은 diff에서 편집 스크립트를 저장한 결과로 1970년대 후반에 나타났습니다.

Algorithm

diff의 연산은 가장 긴 공통 부분수열 문제를 푸는 것을 기반으로 합니다.[4]

이 문제에서, 주어진 두 개의 항목 수열:

a b c d f g h j q z
a b c d e f g i j k r x y z

그리고 우리는 같은 순서로 두 원본 수열 모두에 존재하는 가장 긴 항목의 수열을 찾고 싶습니다. 즉, 우리는 첫 번째 원본 수열에서 일부 항목을 삭제하고 두 번째 원본 수열에서 다른 항목을 삭제함으로써 얻어질 수 있는 새로운 수열을 찾기를 원합니다. 우리는 역시 이 수열을 가능한 길게 되기를 원합니다. 이 경우에서 그것은 가장 긴 공통 하위수열에서 diff와-유사한 출력을 얻는 것은 작은 단계일 뿐입니다:

a b c d  f  g  j  z

만약 항목이 하위수열에는 없지만 첫 번째 원본 수열에 존재하면, 그것은 삭제되어야 합니다 (아래의 '-' 표시로 표시됨). 만약 그것이 하위수열에는 없지만, 두 번째 원본 수열에 있으면, 그것은 삽입되어야 합니다 ('+' 표시로 표시됨).

e   h i   q   k r x y
+   - +   -   + + + +

Usage

diff 명령은 명령줄에서 호출되며, 그것에 두 파일의 이름을 전달합니다: diff original new. 명령의 출력은 original 파일을 new 파일로 변환하기 위해 필요한 변경 사항을 나타냅니다.

만약 originalnew가 디렉토리이면, diff는 두 디렉토리에 존재하는 각 파일에서 실행될 것입니다. 옵션, -r은 일치하는 하위디렉토리를 재귀적으로 감소하면서 디렉토리 사이에 파일을 비교합니다.

이 기사에서 임의의 예제는 다음 두 파일, originalnew를 사용합니다:

이 전통적인 출력 형식에서, a추가됨을 의미하고, d삭제됨이고, c변경됨을 의미합니다. 원본 파일의 줄 번호는 a/d/c 앞에 나타나고 새로운 파일의 줄 번호는 뒤에 나타납니다. 보다-작음보다-큼 기호 (추가, 삭제 또는 변경된 행의 시작 부분)는 행이 나타나는 파일을 나타냅니다. 추가 행은 원본 파일에 추가되어 새로운 파일에 나타납니다. 삭제 줄은 새로운 파일에서 누락되도록 원본 파일에서 삭제됩니다.

기본적으로, 두 파일에 공통적인 행은 표시되지 않습니다. 이동한 줄은 새로운 위치에 추가된 것으로 표시되고 이전 위치에서 삭제된 것으로 표시됩니다.[8] 어쨌든, 일부 diff 도구는 이동된 줄을 강조 표시합니다.

Output variations

Edit script

ed 스크립트-e 옵션과 함께 최신 버전의 diff에서 계속 생성될 수 있습니다. 이 예제의 결과 편집 스크립트는 다음과 같습니다:

24a

This paragraph contains
important new additions
to this document.
.
17c
check this document. On
.
11,15d
0a
This is an important
notice! It should
therefore be located at
the beginning of this
document!

.

ed를 사용하여 original 파일의 내용을 new 파일의 내용으로 변환하기 위해, 우리는 이 diff 파일에 두 줄을 추가해야 하는데, 한 줄은 w (쓰기) 명령을 포함하고, 다른 한 줄은 q (종료) 명령을 포함합니다 (예를 들어, printf "w\nq\n" >> mydiff). 여기서 우리는 diff 파일에 mydiff라는 이름을 부여했고 변환은 ed -s original < mydiff를 실행할 때 일어날 것입니다.

Context format

유닉스의 버클리 배포판은 1981년 7월에 발표된 2.8 BSD에 그들의 기능을 추가하면서, 컨텍스트 형식 (-c)과 파일 시스템 디렉토리 구조에서 재귀하는 기능 (-r)을 추가하는 것을 강조했습니다. 버클리에서 도입된 diff의 컨텍스트 형식은 최소한으로 변경되었을 수 있는 소스 코드에 대해 패치를 배포하는 데 도움이 되었습니다.

컨텍스트 형식에서, 임의의 변경된 행은 전후에 변경되지 않은 행과 함께 표시됩니다. 임의의 변경되지 않은 줄의 숫자의 포함은 패치에 대한 컨텍스트를 제공합니다. 컨텍스트는 두 파일 사이에 변경되지 않은 줄로 구성되고 수정된 파일에서 줄의 위치에 대한 참조 역할을 하고 줄 번호가 여전히 일치하는지 여부에 관계없이 변경 사항을 적용할 의도된 위치를 찾습니다. 컨텍스트 형식은 패치를 적용할 때 사람에게 더 큰 가독성과 안정성을 제공하고, 패치 프로그램에 대한 입력으로 허용되는 출력을 제공합니다. 이 지능형 동작은 전통적인 diff 출력으로는 가능하지 않습니다.

변경 hunk 위와 아래에 표시된 변경되지 않은 줄의 숫자는 심지어 0이라도 사용자에 의해 정의될 수 있지만, 세 줄이 전형적으로 기본값입니다. 만약 덩어리에서 변경되지 않은 줄의 컨텍스트가 인접한 덩어리와 겹치면, diff는 변경되지 않은 줄을 복제하지 않고 덩어리를 단일 덩어리로 병합할 것입니다.

"!"는 두 파일에 해당하는 줄 사이의 변경을 나타냅니다. "+"는 줄의 추가를 나타내지만, 공백 space는 변경되지 않은 줄을 나타냅니다. 패치의 시작 부분에서 탭 문자로 구분된 전체 경로와 타임스탬프를 포함한 파일 정보가 있습니다. 각 덩어리의 시작 부분에서 파일에서 해당 변경 사항에 적용되는 줄 번호가 있습니다. 세 개의 별표의 집합 사이에 나타나는 숫자 범위는 원본 파일에 적용되지만, 세 개의 대시의 집합은 새 파일에 적용됩니다. 덩어리 범위는 해당 파일에서 시작 및 끝 줄 번호를 지정합니다.

명령 diff -c original new는 다음 출력을 생성합니다:

*** /path/to/original	timestamp
--- /path/to/new	timestamp
***************
*** 1,3 ****
--- 1,9 ----
+ This is an important
+ notice! It should
+ therefore be located at
+ the beginning of this
+ document!
+
  This part of the
  document has stayed the
  same from version to
***************
*** 8,20 ****
  compress the size of the
  changes.

- This paragraph contains
- text that is outdated.
- It will be deleted in the
- near future.

  It is important to spell
! check this dokument. On
  the other hand, a
  misspelled word isn't
  the end of the world.
--- 14,21 ----
  compress the size of the
  changes.

  It is important to spell
! check this document. On
  the other hand, a
  misspelled word isn't
  the end of the world.
***************
*** 22,24 ****
--- 23,29 ----
  this paragraph needs to
  be changed. Things can
  be added after it.
+
+ This paragraph contains
+ important new additions
+ to this document.

Note: 여기서, diff 출력은 읽기 쉽도록 색상으로 표시됩니다. diff 유틸리티는 색상 출력을 생성하지 않습니다; 그것의 출력은 일반 텍스트입니다. 어쨌든, 많은 도구는 구문 강조 표시를 사용함으로써 색상으로 출력을 표시할 수 있습니다.

Unified format

통합 형식 (또는 unidiff)은[9][10] 컨텍스트 형식에 의해 만들어진 개선된 기술을 상속하지만, 바로 인접하여 표시되는 이전 텍스트와 새 텍스트로 더 작은 diff를 생성합니다. 통합 형식은 보통 "-u" 명령줄 옵션을 사용하여 호출됩니다. 이 출력은 종종 패치 프로그램에 대한 입력으로 사용됩니다. 많은 프로젝트에서 "diff"를 통합 형식으로 제출하도록 특별히 요청하여, 통합 diff 형식을 소프트웨어 개발자 사이의 교환을 위한 가장 공통적인 형식으로 만듭니다.

통합 컨텍스트 diff는 원래 1990년 8월 Wayne Davison에 의해 개발되었습니다 (comp.sources.misc의 14권에 나타난 unidiff로). Richard Stallman은 한 달 후 GNU 프로젝트의 diff 유틸리티에 통합된 diff 지원을 추가했고, 이 기능은 1991년 1월에 출시된 GNU diff 1.15에서 데뷔했습니다. GNU diff는 이후 임의의 diff 형식을 허용하도록 컨텍스트 형식을 일반화했습니다.

형식은 컨텍스트 형식과 같은 두-줄 머리글로 시작하지만, 원본 파일 앞에 "---"가 있고 새 파일 앞에 "+++"가 오는 것을 제외합니다. 이것에 이어 파일에서 줄 차이를 포함하는 하나 이상의 변경 덩어리입니다. 변경되지 않은, 컨텍스트 행은 공백 문자가 앞에 오고, 추가 행은 더하기 기호가 앞에 오고, 삭제 행은 빼기 기호가 앞에 옵니다.

덩어리는 범위 정보로 시작하고 바로 뒤에 줄 추가, 줄 삭제 및 임의의 수의 컨텍스트 줄이 따라옵니다. 범위 정보는 이중 at 기호로 둘러싸여 있고, 컨텍스트 형식 ()에서 두 줄에 나타나는 것을 한 줄로 결합합니다. 범위 정보 줄의 형식은 다음과 같습니다:

@@ -l,s +l,s @@ optional section heading

덩어리 범위 정보는 둘의 덩어리 범위를 포함합니다. 원본 파일의 덩어리에 대한 범위 앞에는 빼기 기호가 오고, 새 파일에 대한 범위는 더하기 기호가 앞에 옵니다. 각 덩어리 범위는 l,s 형식이며, 여기서 l은 시작 줄 번호이고 s는 덩어리가 각 파일에 적용되는 변경 사항의 줄 수입니다. 많은 버전의 GNU diff에서, 각 범위는 쉼표와 후행 값 s를 생략할 수 있으며, 이 경우에서 s의 기본값은 1입니다. 정말 흥미로운 값은 첫 번째 범위의 l 줄 번호뿐입니다; 모든 다른 값은 diff에서 계산될 수 있습니다.

원본의 덩어리 범위는 모든 문맥 및 삭제 (변경된 포함) 덩어리 줄의 합계여야 합니다. 새로운 파일에 대해 덩어리 범위는 모든 컨텍스트 및 추가 (변경된 포함) 덩어리 줄의 합계여야 합니다. 만약 덩어리 크기 정보가 덩어리에서 줄 수와 일치하지 않으면, diff가 유효하지 않은 것으로 여겨지게 되고 거부될 수 있습니다.

선택적으로, 덩어리 범위 뒤에 덩어리가 속한 섹션 또는 함수의 제목이 올 수 있습니다. 이것은 주로 diff를 읽기 쉽게 만드는 데 유용합니다. GNU diff를 사용하여 diff를 만들 때, 제목은 정규 표현식 일치로 식별됩니다.[11]

만약 줄이 수정되면, 그것은 삭제와 추가로 표시됩니다. 원본 파일과 새 파일의 덩어리가 같은 덩어리에 나타나기 때문에, 그러한 변경 사항은 서로 인접하게 나타납니다.[12] 아래 예제에서 이와 같은 경우는 다음과 같습니다:

-check this dokument. On
+check this document. On

명령 diff -u original new은 다음 출력을 생산합니다:

--- /path/to/original	timestamp
+++ /path/to/new	timestamp
@@ -1,3 +1,9 @@
+This is an important
+notice! It should
+therefore be located at
+the beginning of this
+document!
+
 This part of the
 document has stayed the
 same from version to
@@ -8,13 +14,8 @@
 compress the size of the
 changes.

-This paragraph contains
-text that is outdated.
-It will be deleted in the
-near future.
-
 It is important to spell
-check this dokument. On
+check this document. On
 the other hand, a
 misspelled word isn't
 the end of the world.
@@ -22,3 +23,7 @@
 this paragraph needs to
 be changed. Things can
 be added after it.
+
+This paragraph contains
+important new additions
+to this document.

Note: 여기서, diff 출력은 읽기 쉽도록 색상으로 표시됩니다. diff 유틸리티는 색상 출력을 생성하지 않습니다; 그것의 출력은 일반 텍스트입니다. 어쨌든, 많은 도구는 구문 강조 표시를 사용함으로써 색상으로 출력을 표시할 수 있습니다.

타임스탬프에서 파일 이름을 성공적으로 분리하기 위해, 둘 사이의 구분 기호는 탭 문자임을 주목하십시오. 이것은 화면에 보이지 않고 diff가 콘솔/터미널 화면에서 복사/붙여넣기될 때 손실될 수 있습니다.

특정 프로그램 및 특정 컨텍스트에서 사용 및 이해되는 diff 형식에 대한 일부 수정 및 확장이 있습니다. 예를 들어, Subversion과 같은 일부 개정 제어 시스템은 버전 번호, "작업 사본", 또는 diff의 머리글 섹션에 있는 타임스탬프 대신 또는 추가로 임의의 다른 주석을 지정합니다.

일부 도구는 다음과 같이 보일 수 있는 수정된 각 파일에 대한 머리글을 사용하여 여러 다른 파일에 대해 diff를 하나로 병합할 수 있습니다:

Index: path/to/file.cpp

개행으로 끝나지 않는 파일의 특별한 경우는 처리되지 않습니다. unidiff 유틸리티도 POSIX diff 표준도 이러한 유형의 파일을 처리하는 방법을 정의하지 않습니다. (사실, 그러한 파일은 엄격한 POSIX 정의에 의해 "텍스트" 파일이 아닙니다.[13]) 패치 프로그램은 구현 특정 diff 출력조차 인식하지 못합니다.

Implementations and related programs

1975년 이후의 변경 사항은 핵심 알고리듬 개선, 명령에 유용한 기능 추가, 및 새로운 출력 형식 설계를 포함합니다. 기본 알고리듬은 Eugene W. Myers에 의해 논문 An O(ND) Difference Algorithm and its Variations[14] 및 Webb Miller와 Myers에 의한 A File Comparison Program 논문에 설명되어 있습니다.[15] 그 알고리듬은 Esko Ukkonen에 의한 Algorithms for Approximate String Matching에서 독립적으로 발견되고 설명되었습니다.[16] diff 프로그램의 첫 번째 판은 줄 바꿈 문자가 줄을 구분할 것으로 예상하는 텍스트 파일의 줄 비교를 위해 설계되었습니다. 1980년대까지 바이너리 파일에 대한 지원은 응용 프로그램의 설계 및 구현에 변화를 가져왔습니다.

GNU diff 및 diff3은 diffutils 패키지에 다른 diff 및 패치 관련 유틸리티와 함께 포함되어 있습니다.[17] 요즘에는 컨텍스트 diff와 통합 diff를 결합, 재정렬, 비교 및 수정할 수 있는 patchutils 패키지도 있습니다.[18]

Formatters and front-ends

후처리기 sdiffdiffmk는 나란히 diff 목록을 렌더링하고 인쇄된 문서에 각각 변경 표시를 적용합니다. 둘 다는 1981년 또는 그 이전에 Bell Labs의 다른 곳에서 개발되었습니다.[citation needed][discuss]

Diff3는 두 개의 diff를 조정함으로써 한 파일을 다른 두 파일과 비교합니다. 그것은 원래 Paul Jensen에 의해 공통 소스를 편집하는 두 사람에 의해 만들어진 변경 사항을 조정하기 위해 고안되었습니다. 그것은 역시 병합을 위해 RCS와 같은 개정 제어 시스템에서도 사용됩니다.[19]

Emacs는 패치 파일에 대한 대화식 편집 및 병합 기능을 결합한 사용자 인터페이스에서 패치가 제공할 변경 사항을 표시하기 위한 Ediff를 가집니다.


Vim은 2개에서 8개 파일을 비교하기 위한 vimdiff를 제공하며, 차이점은 색상으로 강조 표시됩니다.[20] 역사적으로 diff 프로그램을 호출하는 동안, 현대 vim은 git의 xdiff 라이브러리 (LibXDiff) 코드의 포크를 사용하여, 향상된 속도와 기능을 제공합니다.[21]

GNU Wdiff[22] 줄-바꿈 또는 다른 열 너비가 있는 경우에도 서면 언어의 텍스트 문서에서 변경된 단어 또는 구문을 표시하는 diff의 프론트 엔드입니다.

colordiff는 'diff'에 대한 Perl 래퍼이고 같은 출력을 생성하지만 꽤 '구문' 강조 표시를 가집니다.[23]

Algorithmic derivatives

구문 구조에 따라 소스 파일을 비교하는 유틸리티는 대부분 일부 프로그래밍 언어에 대한 연구 도구로 구축되었습니다;[24][25][26] 일부는 상용 도구로 사용할 수 있습니다.[27][28] 게다가, 구문-인식 diff를 수행하는 무료 도구는 다음을 포함합니다:

  • C++: zograscope, AST-based.[29]
  • HTML: Daisydiff,[30] html-differ.
  • XML: xmldiffpatch by Microsoft and xmldiffmerge for IBM.[31][32]
  • JavaScript: astii (AST-based).
  • Multi-language: Pretty Diff (format code and then diff)[33]

spiff는, 일반적으로 소스 코드 비교와 관련이 없는 반올림 오류와 공백을 갖는 부동 점 계산에서 차이를 무시하는 diff의 변형입니다. Bellcore는 원본 버전을 작성했습니다.[34][35] HPUX 포트는 최신 공개 릴리스입니다. spiff는 바이너리 파일을 지원하지 않습니다. spiff는 표준 diff 형식에서 표준 출력으로 출력하고 C, Bourne shell, Fortran, Modula-2Lisp 프로그래밍 언어의 입력을 허용합니다.[36][37][34][38][35]

LibXDiff는 1998년부터 많은 알고리듬에 대한 인터페이스를 제공하는 LGPL 라이브러리입니다. Rabin fingerprint와 함께 개선된 Myers 알고리듬이 원래 구현되었지만 (2008년 최종 릴리스 기준)[39] gitlibgit2의 포크는 이후 많은 자체의 확장된 저장소를 가집니다. "히스토그램"이라고 하는 한 알고리듬은 일반적으로 속도와 품질 면에서 원래 Myers 알고리듬보다 훨씬 우수한 것으로 여겨집니다.[40][41] 이것은 Vim에 의해 사용되는 LibXDiff의 최신 버전입니다.[21]

See also

Other free file comparison tools

References

  1. ^ MacKenzie et al. "Binary Files and Forcing Text Comparison" in Comparing and Merging Files with GNU Diff and Patch. Downloaded 28 April 2007. [1]
  2. ^ Eric S. Raymond (ed.), "diff", The Jargon File, version 4.4.7
  3. ^ IEEE Computer Society; The Open Group (26 September 2008). Standard for Information Technology—Portable Operating System Interface (POSIX) Base Specifications, Issue 7. pp. 2599–2607. IEEE Std. 1003.1-2001 specifies traditional, "ed script", and context diff output formats; IEEE Std. 1003.1-2008 added the (by then more common) unified format.
  4. ^ a b James W. Hunt; M. Douglas McIlroy (June 1976). "An Algorithm for Differential File Comparison" (PDF). Computing Science Technical Report, Bell Laboratories. 41.
  5. ^ Larry Wall (November 9, 1984). "A patch applier--YOU WANT THIS!!!". Newsgroupnet.sources. Usenet: 1457@sdcrdcf.UUCP. Retrieved May 11, 2015.
  6. ^ Larry Wall (November 29, 1984). "patch version 1.2--YOU WANT THIS". Newsgroupnet.sources. Usenet: 1508@sdcrdcf.UUCP. Retrieved May 11, 2015.
  7. ^ Larry Wall (May 8, 1985). "patch version 1.3". Newsgroupnet.sources. Usenet: 813@genrad.UUCP. Retrieved May 11, 2015.
  8. ^ David MacKenzie; Paul Eggert; Richard Stallman (1997). Comparing and Merging Files with GNU Diff and Patch. Bristol: Network Theory. ISBN 978-0-9541617-5-0.
  9. ^ "Detailed Description of Unified Format". GNU Diffutils (version 3.7, 7 January 2018).
  10. ^ van Rossum, Guido. "Unified Diff Format". All Things Pythonic.
  11. ^ 2.2.3 Showing Which Sections Differences Are in, GNU diffutils manual
  12. ^ Unified Diff Format by Guido van Rossum, June 14, 2006
  13. ^ http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_403 Section 3.206
  14. ^ E. Myers (1986). "An O(ND) Difference Algorithm and Its Variations". Algorithmica. 1 (2): 251–266. CiteSeerX 10.1.1.4.6927. doi:10.1007/BF01840446. S2CID 6996809.
  15. ^ Webb Miller; Eugene W. Myers (1985). "A File Comparison Program". Software — Practice and Experience. 15 (11): 1025–1040. CiteSeerX 10.1.1.189.70. doi:10.1002/spe.4380151102.
  16. ^ Esko Ukkonen (1985). "Algorithms for Approximate String Matching". Information and Control. 64 (1–3): 100–118. doi:10.1016/S0019-9958(85)80046-2.
  17. ^ GNU Diff utilities. Made available by the Free Software Foundation. Free Documentation. Free source code.
  18. ^ Waugh, Tim (12 June 2020). "twaugh/patchutils".
  19. ^ "merge (GNU RCS 5.10.0)". gnu.org. Retrieved 22 January 2021.
  20. ^ Moolenaar, Bram. "Vim documentation: diff". vimdoc.sourceforge.net. Retrieved 1 May 2020. The easiest way to start editing in diff mode is with the "vimdiff" command. This starts Vim as usual, and additionally sets up for viewing the differences between the arguments. vimdiff file1 file2 [file3] [file4] [...file8] This is equivalent to: vim -d file1 file2 [file3] [file4] [...file8]
  21. ^ a b Brabandt, Christian (1 December 2018). "The power of diff". Vimways. Archived from the original on 2 December 2018. Retrieved 1 May 2020.
  22. ^ "gnu.org". www.gnu.org.
  23. ^ "colordiff". www.colordiff.org.
  24. ^ Horwitz, Susan (June 1990). "Identifying the semantic and textual differences between two versions of a program". ACM SIGPLAN Notices. 25 (6): 234–245. CiteSeerX 10.1.1.49.3377. doi:10.1145/93548.93574.
  25. ^ Yang, Wuu (July 1991). "Identifying syntactic differences between two programs". Software: Practice and Experience. 21 (7): 739–755. CiteSeerX 10.1.1.13.9377. doi:10.1002/spe.4380210706.
  26. ^ Grass. Cdiff: A syntax directed Diff for C++ programs. Proceedings USENIX C++ Conf., pp. 181-193, 1992
  27. ^ Compare++, http://www.coodesoft.com/ Archived 2011-11-29 at the Wayback Machine
  28. ^ SmartDifferencer, http://www.semanticdesigns.com/Products/SmartDifferencer
  29. ^ "xaizek/zograscope". GitHub. 26 May 2020.
  30. ^ DaisyDiff, https://code.google.com/p/daisydiff/
  31. ^ xmldiffpatch, http://msdn.microsoft.com/en-us/library/aa302294.aspx
  32. ^ xmldiffmerge, http://www.alphaworks.ibm.com/tech/xmldiffmerge
  33. ^ Cheney, Austin. Pretty Diff - Documentation. http://prettydiff.com/documentation.php Archived 2012-07-31 at the Wayback Machine
  34. ^ a b dontcallmedotcom. "spiff". Retrieved 2013-06-16.
  35. ^ a b Nachbar, Daniel W (1999-12-01). "HP-UX Porting and Archiving". UK. Retrieved 2013-06-13.
  36. ^ "SPIFF 1". 1988-02-02. Retrieved 2013-06-16.
  37. ^ Nachbar, Daniel W (1988-02-02). "Man page". UK. Retrieved 2013-06-16.
  38. ^ Davide (2009-09-28). "stackoverflow". Retrieved 2013-06-16.
  39. ^ Libenzi, Davide. "LibXDiff". SourceForge FreshMeat.
  40. ^ Nugroho, Yusuf Sulistyo; Hata, Hideaki; Matsumoto, Kenichi (January 2020). "How different are different diff algorithms in Git?: Use --histogram for code changes". Empirical Software Engineering: 790–823. doi:10.1007/s10664-019-09772-z. S2CID 59608676.
  41. ^ "algorithm - What's the difference between 'git diff --patience' and 'git diff --histogram'?". Stack Overflow. This does indeed show that histogram diff slightly beats Myers, while patience is much slower than the others.

Further reading

External links