Git version and version range notation

Many Git commands use revision (revision) as a parameter. Depending on the command, sometimes revision parameter represents a particular submission, sometimes on behalf of a parent of a submit all can be traced to submit (such as git log). In this latter case, typically a range of revisions may also be provided as a parameter. In addition, some commands (e.g. git show) using revision parameter representative of other objects, such as tree objects or blobs.

Specification revision

A revision parameter <rev> Under normal circumstances (but not in all cases) submitted on behalf of a target (commit). It called extended syntax using SHA-1 (extended SHA-1 ) a. Here is the syntax represent a wide variety of revision.

<sha1>, eg dae86e1950b1277e545cee180551750029cfe735, dae86e

Complete SHA-1 ID (40-byte hexadecimal string), or a preamble can be only representative of this sub-string submitted in the warehouse can refer to this submission. In this embodiment, since the leading substring dae86e is unique in the warehouse, it may be used dae86e to represent dae86e1950b1277e545cee180551750029cfe735. If dae86e not the only, just need a few more characters in the warehouse, you can make it unique in the warehouse.
<describeOutput>, eg v1.7.4.2-679-g3bee7fb

git describe command output: contains a Tag, followed by a hyphen, a number of submissions, a hyphen, a character g, and finally a shorthand object ID.
<refname>, eg master, heads/master, refs/heads/master

Symbol references. For example: master usually represents refs / heads / master references to submit object. If your warehouse in the presence of heads / master and tags / master at the same time, in order to master branch representatives, can be explicitly specified as: heads / master. If a reference name appeared ambiguous, then Git processing in accordance with the following rules, the first match found is used.
1. If there is $GIT_DIR/<refname>, use it
2. Otherwise, look for refs/<refname>
3. Otherwise, look for refs/tags/<refname>
4. Otherwise, look for refs/heads/<refname>
5. Otherwise, look for refs/remotes/<refname>
6. Otherwise, look for refs/remotes<refname>/HEAD
@: @ On behalf of a single HEAD
<refname>@{<date>}, eg master@{yesterday}, HEAD@{5 minutes ago}

A reference name, followed by a symbol @, and then followed by a date in the enclosed inside the braces (e.g.: {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} or {1979-02-26 18:30 : 00}) representing the reference value before the period of time. This usage is useful to reference above, can not be used for an exact commit ID, and the reference must exist in the $ GIT_DIR / logs / log record has. Note that this usage will only check the status of your local warehouse at a given point in time. If you want to see in the state a certain time period, use --since and --until parameters.
<refname>@{<n>}, eg master@{1}

Followed by a name of a reference back @ suffix and is a number enclosed in braces, for example ({1}, {15}). N may represent a value of the previous reference. For example, master@{1} the previous value representing master. The master@{5} value of the master before the 5th of the representatives. This usage can only be used on references, and reference must have a reference to the log ( $GIT_DIR/logs/<refname>).
@{<n>}, eg @{1}

If you omit the reference part, the representative of the current branch. For example: If you are currently on the branch blabla, then @ {1} to {1} @ blabla and a meaning.
@{-<n>}, eg @{-1}

@ {-}, this notation, the n-th previous representative of the detected branch or submit. qiandao
<rev>^, eg HEAD^, v1.5.1^0

In a later revision plus a ^ suffix it can be used to refer to directly submit parent revision. ^<n> N represents the parent of submission (e.g., \<rev\>^ and \<rev\>^1 are equivalent). \<rev\>^0 Rev own behalf. When \<rev\> is a tag name, the \<rev\>^0 representation of the tag corresponding to the object of the commit.
<rev>~<n>, eg master~3

In a later revision plus a ~<n> suffix submitted on behalf of the n-th ancestor revision. When the primary user <rev> has a plurality of parent submitted.
:/<text>, eg :/fix nasty bug

A colon, followed by a slash in the back of a string of text. This text string will be treated as a regular expression. Whole :/<text> Representative to submit information matches the regular expression of the last submission. Regular expressions can match any part of the information submitted. If you want to match the beginning of the information submitted, it can be used :/^foo.
<rev>:<path>, eg HEAD:README, :README, master:./README
:<n>:<path>, eg :0:README, :README

The following is a chart showing the various concepts:

 
  G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A
                       
A =      = A^0
B = A^   = A^1     = A~1
C = A^2  = A^2
D = A^^  = A^1^1   = A~2
E = B^2  = A^^2
F = B^3  = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2  = B^^2    = A^^^2  = A~2^2
I = F^   = B^3^    = A^^3^
J = F^2  = B^3^2   = A^^3^2
 
 

Specified range

Those commands need to traverse the history submitted (such as git log) will submit a series of operations carried out, not just for a submission. For these commands, if only to provide a revision of their parameters, then the meaning refers to submit the ancestor of the revision of the chain can be tracked all submissions.

If you want to exclude can be traced to submit a submission from, only need to add the prefix in front of the submissions ^. For example: ^r1 r2 refers can be traced from r2 to be submitted but does not contain all the r1 can be traced to all submissions. This representation is very common, so for ^r1 r2 it to have a shorthand notation: r1..r2(Note: only two periods between r1 and r2 ). Can omit a revision, the revision omitted default is HEAD.

Similar notation: r1...r2 can be called a difference set (mathematical) between r1 and r2, r1 is the track refers to submission or r2 is from track to submission, but does not contain the r1 and r2 are tracked of.

<rev>: Representative from <rev> submission (rev ancestor of all) can be tracked.
^<rev>: It does not include the <rev> submission can be tracked.
<rev1>..<rev2>

From that it contains <rev2> all submissions can be tracked, but does not include the <rev1> submission can be tracked.
<rev1>...<rev2>

It contains from <rev1> or <rev2> traceable to submit, but does not include the submission from both can be tracked. This range represented together with one of confusion method. The above two points, and this is the three points. Way of example, in the above illustration, D..F range represented only submit F., And D ... F., Submitted range indicated with a D and F.
<rev>^@, eg HEAD^@

On behalf of <rev> all parent submit, it is to submit all track from its parent filed, but does not include its own.
<rev>^!, eg HEAD^!

Here are some examples:

D                G H D
D F              G H I J D F
^G D             H D
^D B             E I J F B
B..C             C
B...C            G H D E B C
^D B C           E I J F B C
C                I J F C
C^@              I J F
C^!              C
F^! D            G H D F