three dots in git

What are the differences between double-dot “..” and triple-dot “…” in Git commit ranges?

Using Commit Ranges with Git Log

When you're using commit ranges like .. and ... with 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?.

See Also

• Pro Git § 6.1 Git Tools - Revision Selection - Commit Ranges

https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection#Commit-Ranges

Double Dot

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..

Figure 137. Example history for range selection.

Say you want to see what is in your experiment branch that hasn’t yet been merged into your masterbranch.

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 experiment:

$ 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.

Multiple Points

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 refA or 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.

Triple Dot

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 master or 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.

https://git-scm.com/docs/gitrevisions#Documentation/gitrevisions.txt-Theem82308203emthree-dotSymmetricDifferenceNotation

SPECIFYING RANGES

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.

Commit Exclusions

^<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.

https://public-inbox.org/git/nycvar.QRO.7.76.6.1905281154390.44@tvgsbejvaqbjf.bet/

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