Editing Diff (section)

== Output variations{{anchor|variations}} ==

=== Edit script ===
An [[Ed (text editor)|ed script]] can still be generated by modern versions of diff with the <code>-e</code> option. The resulting edit script for this example is as follows:

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

In order to transform the content of file ''original'' into the content of file ''new'' using {{Mono|ed}}, we should append two lines to this diff file, one line containing a <code>w</code> (write) command, and one containing a <code>q</code> (quit) command (e.g. by {{code|lang=bash|printf "w\nq\n" >> mydiff}}). Here we gave the diff file the name ''mydiff'' and the transformation will then happen when we run {{code|lang=bash|ed -s original < mydiff}}.

=== Context format ===
The [[BSD|Berkeley distribution of Unix]] made a point of adding the ''context format'' ({{code|-c}}) and the ability to recurse on filesystem directory structures ({{code|-r}}), adding those features in 2.8 BSD, released in July 1981. The context format of diff introduced at Berkeley helped with distributing patches for source code that may have been changed minimally.

In the context format, any changed lines are shown alongside unchanged lines before and after. The inclusion of any number of unchanged lines provides a ''context'' to the patch. The ''context'' consists of lines that have not changed between the two files and serve as a reference to locate the lines' place in a modified file and find the intended location for a change to be applied regardless of whether the line numbers still correspond. The context format introduces greater readability for humans and reliability when applying the patch, and an output which is accepted as input to the [[patch (Unix)|patch]] program. This intelligent behavior is not possible with the traditional diff output.

The number of unchanged lines shown above and below a change ''hunk'' can be defined by the user, even zero, but three lines is typically the default. If the context of unchanged lines in a hunk overlap with an adjacent hunk, then diff will avoid duplicating the unchanged lines and merge the hunks into a single hunk.

A "{{code|!}}" represents a change between lines that correspond in the two files, whereas a "{{code|+}}" represents the addition of a line, and a "{{code|-}}" the removal of a line. A blank [[space (punctuation)|space]] represents an unchanged line. At the beginning of the patch is the file information, including the full path and a [[time stamp]] delimited by a tab character. At the beginning of each hunk are the line numbers that apply for the corresponding change in the files. A number range appearing between sets of three asterisks applies to the original file, while sets of three dashes apply to the new file. The hunk ranges specify the starting and ending line numbers in the respective file.

The command {{code|diff -c original new}} produces the following output:
<syntaxhighlight lang="diff">
*** /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.
</syntaxhighlight>
'''Note''': ''Here, the diff output is shown with colors to make it easier to read. The diff utility does not produce colored output; its output is [[plain text]]. However, many tools can show the output with colors by using [[syntax highlighting]].''

=== Unified format ===
The ''unified format'' (or ''unidiff'')<ref>{{Cite web|url=https://www.gnu.org/software/diffutils/manual/html_node/Detailed-Unified.html|title=Detailed Description of Unified Format|website=GNU Diffutils (version 3.7, 7 January 2018)|access-date=29 January 2020|archive-date=18 January 2020|archive-url=https://web.archive.org/web/20200118142136/http://www.gnu.org/software/diffutils/manual/html_node/Detailed-Unified.html|url-status=live}}</ref><ref>{{Cite web|url=https://www.artima.com/weblogs/viewpost.jsp?thread=164293|title=Unified Diff Format|last=van Rossum|first=Guido|website=All Things Pythonic|access-date=2020-01-29|archive-date=2019-12-25|archive-url=https://web.archive.org/web/20191225234517/https://www.artima.com/weblogs/viewpost.jsp?thread=164293|url-status=live}}</ref> inherits the technical improvements made by the context format, but produces a smaller diff with old and new text presented immediately adjacent. Unified format is usually invoked using the "<code>-u</code>" [[command-line option]]. This output is often used as input to the [[patch (Unix)|patch]] program. Many projects specifically request that "diffs" be submitted in the unified format, making unified diff format the most common format for exchange between software developers.

Unified context diffs were originally developed by Wayne Davison in August 1990 (in '''unidiff''' which appeared in Volume 14 of comp.sources.misc). [[Richard Stallman]] added unified diff support to the [[GNU|GNU Project]]'s diff utility one month later, and the feature debuted in '''GNU diff''' 1.15, released in January 1991. GNU diff has since generalized the context format to allow arbitrary formatting of diffs.

The format starts with the same two-line [[Header (computing)|header]] as the context format, except that the original file is preceded by "<samp>---</samp>" and the new file is preceded by "<samp>+++</samp>". Following this are one or more '''change hunks''' that contain the line differences in the file. The unchanged, contextual lines are preceded by a space character, addition lines are preceded by a [[plus sign]], and deletion lines are preceded by a [[minus sign]].

A hunk begins with '''range information''' and is immediately followed with the line additions, line deletions, and any number of the contextual lines. The range information is surrounded by double [[at sign]]s, and combines onto a single line what appears on two lines in the context format ([[#Context format|above]]). The format of the range information line is as follows:

 @@ -l,s +l,s @@ ''optional section heading''<!-- <syntaxhighlight lang="text"> ruins the italics -->

The hunk range information contains two hunk ranges. The range for the hunk of the original file is preceded by a minus symbol, and the range for the new file is preceded by a plus symbol. Each hunk range is of the format ''l,s'' where ''l'' is the starting line number and ''s'' is the number of lines the change hunk applies to for each respective file. In many versions of GNU diff, each range can omit the comma and trailing value ''s'', in which case ''s'' defaults to 1. Note that the only really interesting value is the ''l'' line number of the first range; all the other values can be computed from the diff.

The hunk range for the original should be the sum of all contextual and deletion (including changed) hunk lines. The hunk range for the new file should be a sum of all contextual and addition (including changed) hunk lines. If hunk size information does not correspond with the number of lines in the hunk, then the diff could be considered invalid and be rejected.

Optionally, the hunk range can be followed by the heading of the section or function that the hunk is part of. This is mainly useful to make the diff easier to read. When creating a diff with GNU diff, the heading is identified by [[regular expression]] matching.<ref>[https://www.gnu.org/software/diffutils/manual/html_node/Sections.html 2.2.3 Showing Which Sections Differences Are in], GNU diffutils manual</ref>

If a line is modified, it is represented as a deletion and addition. Since the hunks of the original and new file appear in the same hunk, such changes would appear adjacent to one another.<ref>[http://www.artima.com/weblogs/viewpost.jsp?thread=164293 Unified Diff Format] by [[Guido van Rossum]], June 14, 2006</ref>
An occurrence of this in the example below is:

<pre>
-check this dokument. On
+check this document. On
</pre>

The command <code>diff -u original new</code> produces the following output:
<syntaxhighlight lang="diff">
--- /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.
</syntaxhighlight>
'''Note''': ''Here, the diff output is shown with colors to make it easier to read. The diff utility does not produce colored output; its output is [[plain text]]. However, many tools can show the output with colors by using [[syntax highlighting]].''

Note that to successfully separate the file names from the timestamps, the delimiter between them is a tab character. This is invisible on screen and can be lost when diffs are copy/pasted from console/terminal screens.

=== Extensions ===
There are some modifications and extensions to the diff formats that are used and understood by certain programs and in certain contexts. For example, some [[revision control]] systems—such as [[Subversion (software)|Subversion]]—specify a version number, "working copy", or any other comment instead of or in addition to a timestamp in the diff's header section.

Some tools allow diffs for several different files to be merged into one, using a header for each modified file that may look something like this:

 Index: path/to/file.cpp

The special case of files that do not end in a newline is not handled. Neither the unidiff utility nor the POSIX diff standard define a way to handle this type of files. (Indeed, such files are not "text" files by strict POSIX definitions.<ref>http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_403 {{Webarchive|url=https://web.archive.org/web/20130429195728/http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_403 |date=2013-04-29 }} Section 3.206</ref>) GNU diff and git produce "\ No newline at end of file" (or a translated version) as a diagnostic, but this behavior is not portable.<ref>{{cite web |title=Incomplete Lines (Comparing and Merging Files) |url=https://www.gnu.org/software/diffutils/manual/html_node/Incomplete-Lines.html |website=www.gnu.org}}</ref> GNU patch does not seem to handle this case, while git-apply does.<ref>{{cite web |title=git: apply.c |url=https://github.com/git/git/blob/69c786637d7a7fe3b2b8f7d989af095f5f49c3a8/apply.c#LL2901C35-L2901C39 |publisher=Git |date=8 May 2023}}</ref>

The [[Patch (Unix)|patch]] program does not necessarily recognize implementation-specific diff output. GNU patch is, however, known to recognize git patches and act a little differently.<ref>{{cite web |title=patch.c\src - patch.git - GNU patch |url=https://git.savannah.gnu.org/cgit/patch.git/tree/src/patch.c?id=c835ecc67b7e37c0d0b7dd7e032209fdaa285808#n1919 |website=git.savannah.gnu.org |quote=In git-style diffs, the "before" state of each patch refers to the initial state before modifying any files,..}}</ref>