The diff tool produces output that shows the differences between two files:

$ diff dir1/foo dir2/foo
1c1
< foo1
---
> foo2
$ 

This is a simple format that specifies that line one in the first file (dir1/foo) gets changed to become line 1 in the second file. Depending on the contents of the two files, there might also be deletions and additions.

diff output is a concise way to show to a human what has been changed. For example, you might have shown one version of your code to a friend, and then made some changes. Instead of having the friend re-read all the code, they can just read the diff output.

Sometimes the friend is yourself in the future, wondering what in all that is precious did you actually do to the code today.

The default output form of diff is not very nice to read, for a human. Luckily, diff can output has several variations (see diff formats), and the "unified context diff" (diff -u) is very popular, and quite easy for humans to read. The default format is the default because of backwards compatibility, possibly all the way back to the 1970s, when diff was originally written for Unix.

Here is a real example of unified context diff output:

diff --git a/debian/changelog b/debian/changelog
index 9ef157b..7e5ef03 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,10 +1,11 @@
 obnam (1.8-1) UNRELEASED; urgency=low

   * New upstream release.
-  * Fix "typo in debian/control: s/Uploader/Uploaders/" <explain what
-    you changed and why> (Closes: #729347)
+    * Fix "obnam mount fails to retrieve files over 64KB (obnam restore
+      works fine)" (Closes: #741968)
+  * Fix "typo in debian/control: s/Uploader/Uploaders/" (Closes: #729347)

- -- Lars Wirzenius <liw@liw.fi>  Sun, 16 Mar 2014 12:47:32 +0000
+ -- Lars Wirzenius <liw@liw.fi>  Tue, 18 Mar 2014 08:42:28 +0000

 obnam (1.7-1) unstable; urgency=low

This shows that the file debian/changelog got changed, and which lines got changed. Lines that start with "-" indicate deletions; those with "+" indicate additions. The other lines are there for context, making it easier for a human to understand what was actually changed.

Read more details in the diff Wikipedia page. You rarely need to know the precise, minute details of the format. The overall gist is easy to get, and that's good, because you will be seeing these diff outputs all the time.

If you need to send a diff to someone else, always use the unified context diff format. You might send it to someone to show how you've fixed a bug in their software, for example. Because a unified diff can be applied even after other parts of the file have changed, it is a very convenient form of exchanging changes, or sets of changes, between programmers.

For example, the above example isn't actually from diff itself. Instead, it's from git log -p, which shows a unified diff with the changes for each commit.

The patch utility reads diff output and makes the changes in the second file. In this sense it is the reverse of diff. The output of diff is thus often called a patch as well, especially when the diff is sent to someone to be applied with patch. Instead of patch, the patch may also be applied with a suitable tool in the version control system being used, such as git am.