Diff

Before following this post, make sure you have already set up everything from my other post regarding the configuration of the git environment.

Diff command will allow you to compare two different commits, let’s set up a repository:

Now in the second repository, we make some changes:

now let’s back to the first repository and see the changes:

now you should see all the differences in meld:

To find diff between current and previous commit:

As of Git 1.8.5, @ is an alias for HEAD, so you can use:

If you want to know the diff between head and any commit you can use:

You can add -t to select your difftool such kdiff3, meld, etc.
To see the diff with gitk, first, go to Edit>Preference and set the external difftool.
Now click on your revision, then right-click on the revision that you want to compare to and click on Diff this-> selected. Now on the bottom window right click on any of the changed files and select External diff

Compare the local repo with its remote branch

to see what the push will do to your local repo.

Git diff Two-dot (A..B) and Three-dot (A…B) comparison

You can compare two commits with two dots, This will show all differences, including C, D, F0, F1

But this will show you only F0 and F1

and this will show you only C and D

The following images show the differences:

Merge and conflict

Now let’s merge all the changes. If you make some changes on different files, you will do fast-forward. That means you only incorporate new changes and everything is OK afterward. But if you made some changes on the same file along the same lines, then you have a merge conflict, and you should do a three-way merge.

To show you the point, let’s make some changes in the first repository in the file A.txt.

now if you call git merge, you will get a merge conflict, to solve this call the following:

and you will get this in meld:

and this in kdiff:

+————————————–+
| LOCAL | BASE | REMOTE |
+————————————–+
|                MERGED               |
+————————————–+

LOCAL: Your side of the conflict – i.e., your branch (HEAD) that will contain the results of the merge
REMOTE: The remote side of the conflict – the branch you are merging into HEAD.
BASE: The common ancestor of both local and remote. Useful for feeding into a three-way merge tool
MERGED: The result of the automatic merge.

Go through the conflict and choose the side (A, B, or C) and see the merged file in the window below and save and close.

Use the command line and interpret the output of git diff

diff uses Levenshtein distance and tries to determine the smallest set of deletions and insertions. The output is called a “diff”, or a patch since the output can be applied with the Unix program patch

The POSIX standard specifies the behavior of the “diff” and “patch” utilities and their file formats. You can call the following to see the difference between any two files or directories:

For instance in our case:

-u  indicate unified format

Git also uses a unified format. If you call

You will get the following:

Let’s interpret the output:
1) The first line diff --git a/A.txt b/A.txt is a “git diff” header in the form diff –git a/file1 b/file2. The a/ and b/ filenames are the same unless rename/copy is involved. The –git is to mean that diff is in the “git” diff format.
2) In the last line in the extended diff header is:

100644 is the mode of the given file which means that it is an ordinary file and not e.g. symlink and that it doesn’t have executable permission bit, and about the shortened hash of preimage (the version of the file before the given change) and post image (the version of the file after change).
3) Next is a two-line unified diff header

The original file is preceded by “—” and the new file is preceded by “+++“.

4) Following this are one or more change hunks that contain the line differences in the file. Unified format hunks start with a line like:

5) Next comes the description of where files differ. The lines common to both files begin with a space character. The lines that actually differ between the two files have one of the following indicator characters in the left print column:

• ‘+’ — A line was added here to the first file.
• ‘-‘ — A line was removed here from the first file.

Refs: 1, 2, 3

Compare two different commits on the same branch in GitHub

if you click on the last commit, you can get the list of all commits,

Click on the copy button of the commits that you want to compare,

Now Just add the word compare to the end of the repository URL, i.e.

basically, the end result should be the following URL:

You can use two-dots or three-dots for comparison.

git blame

The git blame command is used to know who/which commit is responsible for the latest changes made to a file. The author/commit of each line can also been seen. git blame does not show the per-line modifications history in the chronological sense. It only shows who was the last person to have changed a line in a document up to the last commit in HEAD.

Line between 2 and 4:

2 lines after 2:

Make the output shorter:

Only display email of the auther:

get the blame for a specifi commit:

When the commit ID is 00000000000 it means I have changed that line locally.

git blame does not show the per-line modifications history in the chronological sense. It only shows who was the last person to have changed a line in a document up to the last commit in HEAD.
In order to see the full history/log of a document line, you would need to run a git blame path/to/file for each commit in your git log. Since Git 1.8.4, you can use git log has -L to view the evolution of a range of lines.

Refs: 1, 2

View a single file’s history in GitK

or

Compare a single file with its previous version