-#### 2.4.1 Changesets, revisions, and talking to other people
-
-As English is a notoriously sloppy language, and computer science has a hallowed history of terminological confusion (why use one term when four will do?), revision control has a variety of words and phrases that mean the same thing. If you are talking about Mercurial history with other people, you will find that the word “changeset” is often compressed to “change” or (when written) “cset”, and sometimes a changeset is referred to as a “revision” or a “rev”.
-
-While it doesn’t matter what word you use to refer to the concept of “a changeset”, the identifier that you use to refer to “a specific changeset” is of great importance. Recall that the changeset field in the output from “hg log” identifies a changeset using both a number and a hexadecimal string.
-
- * The revision number is only valid in that repository,
- * while the hex string is the permanent, unchanging identifier that will always identify that exact changeset in every copy of the repository.
-
-This distinction is important. If you send someone an email talking about “revision 33”, there’s a high likelihood that their revision 33 will not be the same as yours. The reason for this is that a revision number depends on the order in which changes arrived in a repository, and there is no guarantee that the same changes will happen in the same order in different repositories. Three changes a,b,c can easily appear in one repository as 0,1,2, while in another as 1,0,2.
-
-Mercurial uses revision numbers purely as a convenient shorthand. If you need to discuss a changeset with someone, or make a record of a changeset for some other reason (for example, in a bug report), use the hexadecimal identifier.
-
-#### 2.4.2 Viewing specific revisions
-
-To narrow the output of “hg log” down to a single revision, use the -r (or --rev) option. You can use either a revision number or a long-form changeset identifier, and you can provide as many revisions as you want.
-
-1 $ hg log -r 3
-2 changeset: 3:ff5d7b70a2a9
-3 user: Bryan O'Sullivan <bos@serpentine.com>
-4 date: Tue Sep 06 13:15:58 2005 -0700
-5 summary: Get make to generate the final binary from a .o file.
-6
-7 $ hg log -r ff5d7b70a2a9
-8 changeset: 3:ff5d7b70a2a9
-9 user: Bryan O'Sullivan <bos@serpentine.com>
-10 date: Tue Sep 06 13:15:58 2005 -0700
-11 summary: Get make to generate the final binary from a .o file.
-12
-13 $ hg log -r 1 -r 4
-14 changeset: 1:82e55d328c8c
-15 user: mpm@selenic.com
-16 date: Fri Aug 26 01:21:28 2005 -0700
-17 summary: Create a makefile
-18
-19 changeset: 4:b57f9a090b62
-20 tag: tip
-21 user: Bryan O'Sullivan <bos@serpentine.com>
-22 date: Tue Sep 06 15:43:07 2005 -0700
-23 summary: Trim comments.
-24
-
-If you want to see the history of several revisions without having to list each one, you can use range notation; this lets you express the idea “I want all revisions between a and b, inclusive”.
-
-1 $ hg log -r 2:4
-2 changeset: 2:057d3c2d823c
-3 user: Bryan O'Sullivan <bos@serpentine.com>
-4 date: Tue Sep 06 13:15:43 2005 -0700
-5 summary: Introduce a typo into hello.c.
-6
-7 changeset: 3:ff5d7b70a2a9
-8 user: Bryan O'Sullivan <bos@serpentine.com>
-9 date: Tue Sep 06 13:15:58 2005 -0700
-10 summary: Get make to generate the final binary from a .o file.
-11
-12 changeset: 4:b57f9a090b62
-13 tag: tip
-14 user: Bryan O'Sullivan <bos@serpentine.com>
-15 date: Tue Sep 06 15:43:07 2005 -0700
-16 summary: Trim comments.
-17
-
-Mercurial also honours the order in which you specify revisions, so “hg log -r 2:4” prints 2,3,4 while “hg log -r 4:2” prints 4,3,2.
+#### 2.4.1 Commits, revisions, and talking to other people
+
+As English is a notoriously sloppy language, and computer science has
+a hallowed history of terminological confusion (why use one term when
+four will do?), revision control has a variety of words and phrases
+that mean the same thing. If you are talking about git history
+with other people, you will find that what we have called a “commit”
+is often called a "revision". In other systems, a similar notion
+is referred to as a "changeset". You might even see abbreviations of
+these terms such as "rev", "change", or even "cset".
+
+While it may not matter much what word you use to refer to the concept
+of “a commit”, it's important to know how to name “a specific
+commit”. We have already seen one means of referring to a particular
+commit, the 40-character hexadecimal string shown by "git log". These
+commit identifiers are powerful because they are permanent, unique
+identifiers that always identify the same commit in any copy of a
+repository. If two users are examining a working directory associated
+with the same commit identifier, then those two users have precisely
+the same contents in all files, and exactly the same history leading
+to that commit.
+
+So there are places where it is often important to archive the
+complete commit identifier, (perhaps in bug-tracking systems to
+indicate a specific commit that fixes a bug, for example). But often,
+in more casual settings, it's more convenient to use abbreviated
+commit identifiers. Git accept any unique prefix of a commit
+identifier, (and for reasonably-sized project the first 8 or 10
+characters are almost always unique).
+
+And unlike the permanent commit identifiers, git also provides
+transient means of identifying commits. In fact, in day-to-day use of
+git, you will probably use these names more than commit
+identifiers. One example is branch names, (such as the default
+"master" branch in any git repository), or any project-specific branch
+names such as "stable", "experimental", or "crazy-insane-changes". Git
+also provides a special name "HEAD" which always refers to the current
+branch.
+
+#### 2.4.2 Naming related commits
+
+Git offers simple ways to name revisions that are related to
+particular revisions in the history. One syntax is the ~ suffix which
+refers to the parent of a commit, or if followed by a number, to the
+Nth parent. For example, since "HEAD" refers to the most recent commit
+in the current branch, "HEAD~", refers to the previous commit, and
+"HEAD~2" refers to two commits back in the history.
+
+Another useful syntax is .. which can be used to specify a range of
+commits. So "origin..master" specifies everything that has been
+committed to master since it derived from origin.
+
+#### 2.4.3 Viewing specific revisions
+
+You can use "git log" to explore the range syntax just introduced. For
+example, to see a list of the most recent 3 revisions you can use
+"HEAD~3..", (the destination of the range is implicitly HEAD in this
+case):
+
+ $ git log HEAD~3..
+ commit a1a0e8b392b17caf50325498df54802fe3c03710
+ Author: Bryan O'Sullivan <bos@serpentine.com>
+ Date: Tue Sep 6 15:43:07 2005 -0700
+
+ Trim comments.
+
+ commit 72d4f10e4a27dbb09ace1503c20dbac1912ee451
+ Author: Bryan O'Sullivan <bos@serpentine.com>
+ Date: Tue Sep 6 13:15:58 2005 -0700
+
+ Get make to generate the final binary from a .o file.
+
+ commit 13ed136b983a9c439eddeea8a1c2076cffbb685f
+ Author: Bryan O'Sullivan <bos@serpentine.com>
+ Date: Tue Sep 6 13:15:43 2005 -0700
+
+ Introduce a typo into hello.c.
+
+#### 2.4.4 Other log filters
+
+Besides filtering by commit identifiers, git allows you to easily
+filter the log output according to which files (or directories) are
+modified by listing them after "--" wihch is necessary to distinguish
+commit names from file names:
+
+ $ git log -- Makefile
+ commit 72d4f10e4a27dbb09ace1503c20dbac1912ee451
+ Author: Bryan O'Sullivan <bos@serpentine.com>
+ Date: Tue Sep 6 13:15:58 2005 -0700
+
+ Get make to generate the final binary from a .o file.
+
+ commit 0a633bf58b45fcf1a8299d3c82cd1fd26d3f48f2
+ Author: Bryan O'Sullivan <mpm@selenic.com>
+ Date: Fri Aug 26 01:21:28 2005 -0700
+
+ Create a makefile
+
+And "git log" can also filter based on the dates at which commits were
+created:
+
+ $ git log --since="2 weeks ago" --until="yesterday"
+
+Another useful option is --max-count which, unsurprisingly, limits the
+maximum number of commits to be displayed.