Patch File Viewer

A patch is a text file that describes the difference between two versions of some files. Mailing lists use them, pull requests are built from them, and bug reports contain them. In plain text a diff is hard to read once it has more than a few lines, because the signs and line counts blur together. This viewer lays one out with the old and new line numbers and a colour for each kind of line.

The shape of a unified diff

The unified format begins each file with two header lines, — for the old file and +++ for the new one. Then come hunks, each starting with a header like @@ -1,5 +1,6 @@ followed by the lines of the hunk. A line starting with a space is context, unchanged; a minus marks a line removed from the old file, a plus a line added in the new one. Git adds a line starting with diff –git before each file and extended headers such as index, new file mode, deleted file mode and rename from.

The hunk header

The numbers in @@ -a,b +c,d @@ say where the hunk applies. The old file’s part starts at line a and spans b lines; the new file’s part starts at line c and spans d lines. If the count is left out, it is 1. The viewer shows the header as written and uses the numbers to count lines on each side, which is how it prints two columns of line numbers. A mismatch between the counts and the lines that follow is an error, since a patch tool would reject the same file.

Statuses and totals

The page marks each file as modified, new file, deleted, renamed or binary. A new file has an empty old side and a deleted file an empty new side. A rename can be pure, with no hunks, so the viewer says that no lines are shown. Binary changes, which git summarises in one line, are listed without content. At the top you see the number of files and the totals of added and removed lines.

Pasted patches

Patches copied from a web page or an email often lose trailing spaces, so a blank context line, which should be a single space, becomes an empty line and no longer matches the hunk counts. The viewer detects this inside a hunk and puts the space back, so a patch that was damaged only in that way is still read. It does not repair other changes, such as text that was wrapped into two lines.

A worked example

The Sample button loads a two-file patch. The first file, src/greet.js, is modified: the hunk @@ -1,5 +1,6 @@ removes the line returning “Hello “ + name, adds two lines with a cleaning step and a new return, and replaces the export line, for +3 and −2. The second, old.txt, is deleted and its hunk @@ -1,2 +0,0 @@ removes two lines. The summary shows 2 files, 3 lines added and 4 lines removed. Context lines carry both an old and a new number, removed lines only an old one and added lines only a new one.

Limits

The page displays patches; it does not apply, reverse or check them against files, and it does not do word-level or intra-line highlighting. Combined diffs from merge commits are not supported. Very large patches are shown in full and can be slow to render. Binary patches in git’s encoded form show the file name only. To compare two texts and get a diff, the Diff Checker is the tool for that job.

Related tools

• Diff Checker compares two pieces of text and shows the difference.
• Regex Tester can search the patch text for patterns.
• Glob Tester checks which of the changed paths a pattern covers.
• Source Map Decoder maps a minified error back to the source you are patching.