Using Commit Ranges with Git Log
When you're using commit ranges like
git log, the difference between them is that, for branches A and B,
git log A..B
will show you all of the commits that B has that A doesn't have, while
git log A...B
will show you both the commits that A has and that B doesn't have, and the commits that B has that A doesn't have, or in other words, it will filter out all of the commits that both A and B share, thus only showing the commits that they don't both share.
Visualization with Venn Diagrams & Commit Trees
Here is a visual representation of
git log A..B. The commits that branch B contains that don't exist in A is what is returned by the commit range, and is highlighted in red in the Venn diagram, and circled in blue in the commit tree:
These are the diagrams for
git log A...B. Notice that the commits that are shared by both branches are not returned by the command:
Making the Triple-Dot Commit Range
... More Useful
You can make the triple-dot commit range
... more useful in a log command by using the
--left-right option to show which commits belong to which branch:
$ git log --oneline --decorate --left-right --graph master...origin/master < 1794bee (HEAD, master) Derp some more > 6e6ce69 (origin/master, origin/HEAD) Add hello.txt
In the above output, you'll see the commits that belong to
master are prefixed with
<, while commits that belong to
origin/master are prefixed with
Using Commit Ranges with Git Diff
Someday I might add my own explanation for how the commit ranges work with
git diff, but for now, you might want to check out What are the differences between double-dot ".." and triple-dot "..." in Git diff commit ranges?.
The most common range specification is the double-dot syntax.
This basically asks Git to resolve a range of commits that are reachable from one commit but aren’t reachable from another.
For example, say you have a commit history that looks like Example history for range selection..
Say you want to see what is in your
experiment branch that hasn’t yet been merged into your
You can ask Git to show you a log of just those commits with
master..experiment — that means “all commits reachable from experiment that aren’t reachable from master.”
For the sake目的 of brevity简洁 and clarity清楚 in these examples, the letters of the commit objects from the diagram are used in place of the actual log output in the order that they would display:
$ git log master..experiment D C
If, on the other hand, you want to see the opposite — all commits in
master that aren’t in
experiment — you can reverse the branch names.
experiment..master shows you everything in
master not reachable from
$ git log experiment..master F E
This is useful if you want to keep the
experiment branch up to date and preview what you’re about to merge. Another frequent use of this syntax is to see what you’re about to push to a remote:
$ git log origin/master..HEAD
This command shows you any commits in your current branch that aren’t in the
master branch on your
origin remote. If you run a
git push and your current branch is tracking
origin/master, the commits listed by
git log origin/master..HEAD are the commits that will be transferred to the server. You can also leave off one side of the syntax to have Git assume
HEAD. For example, you can get the same results as in the previous example by typing
git log origin/master.. — Git substitutes
HEAD if one side is missing.
The double-dot syntax is useful as a shorthand, but perhaps you want to specify more than two branches to indicate your revision, such as seeing what commits are in any of several branches that aren’t in the branch you’re currently on. Git allows you to do this by using either the
^ character or
--not before any reference from which you don’t want to see reachable commits. Thus, the following three commands are equivalent:
$ git log refA..refB $ git log ^refA refB $ git log refB --not refA
This is nice because with this syntax you can specify more than two references in your query, which you cannot do with the double-dot syntax. For instance, if you want to see all commits that are reachable from
refB but not from
refC, you can use either of:
$ git log refA refB ^refC $ git log refA refB --not refC
This makes for a very powerful revision query system that should help you figure out what is in your branches.
The last major range-selection syntax is the triple-dot syntax, which specifies all the commits that are reachable by either of two references but not by both of them. Look back at the example commit history in Example history for range selection.. If you want to see what is in
experiment but not any common references, you can run:
$ git log master...experiment F E D C
Again, this gives you normal
log output but shows you only the commit information for those four commits, appearing in the traditional commit date ordering.
A common switch to use with the
log command in this case is
--left-right, which shows you which side of the range each commit is in. This helps make the output more useful:
$ git log --left-right master...experiment < F < E > D > C
With these tools, you can much more easily let Git know what commit or commits you want to inspect.
History traversing commands such as
git log operate on a set of commits, not just a single commit.
For these commands, specifying a single revision, using the notation described in the previous section, means the set of commits
reachable from the given commit.
A commit’s reachable set is the commit itself and the commits in its ancestry chain.
- ^<rev> (caret) Notation
To exclude commits reachable from a commit, a prefix ^ notation is used. E.g. ^r1 r2 means commits reachable from r2 but exclude the ones reachable from r1 (i.e. r1 and its ancestors).
Dotted Range Notations
- The .. (two-dot) Range Notation
The ^r1 r2 set operation appears so often that there is a shorthand for it. When you have two commits r1and r2 (named according to the syntax explained in SPECIFYING REVISIONS above), you can ask for commits that are reachable from r2 excluding those that are reachable from r1 by ^r1 r2 and it can be written as r1..r2.
- The … (three-dot) Symmetric Difference Notation
A similar notation r1...r2 is called symmetric difference of r1 and r2 and is defined as r1 r2 --not $(git merge-base --all r1 r2). It is the set of commits that are reachable from either one of r1 (left side) or r2(right side) but not from both.
In these two shorthand notations, you can omit one end and let it default to HEAD. For example, origin..is a shorthand for origin..HEAD and asks "What did I do since I forked from the origin branch?" Similarly, ..origin is a shorthand for HEAD..origin and asks "What did the origin do since I forked from them?" Note that .. would mean HEAD..HEAD which is an empty range that is both reachable and unreachable from HEAD.
From https://git-scm.com/docs/gitrevisions#Documentation/gitrevisions.txt-Theem82308203emthree-dotSymmetricDifferenceNotation: The ... (three-dot) Symmetric Difference Notation A similar notation r1...r2 is called symmetric difference of r1 and r2 and is defined as r1 r2 --not $(git merge-base --all r1 r2). It is the set of commits that are reachable from either one of r1 (left side) or r2 (right side) but not from both. Most importantly, the next paragraph states: In these two shorthand notations, you can omit one end and let it default to HEAD. What it does *not* say is that you can leave out both ends, in which case it becomes the non-sensical short form of `HEAD...HEAD`, as Hannes pointed out. Ciao, Johannes