зеркало из https://github.com/microsoft/git.git
Merge branch 'mg/revision-doc'
* mg/revision-doc: Documentation: link to gitrevisions rather than git-rev-parse Documentation: gitrevisions Documentation: split off rev doc into include file
This commit is contained in:
Junio C Hamano
Коммит
cb597adb5c
|
|
@ -6,7 +6,7 @@ MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
|
|||
gitrepository-layout.txt
|
||||
MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
|
||||
gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
|
||||
gitdiffcore.txt gitworkflows.txt
|
||||
gitdiffcore.txt gitrevisions.txt gitworkflows.txt
|
||||
|
||||
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
|
||||
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ OPTIONS
|
|||
<object>::
|
||||
The name of the object to show.
|
||||
For a more complete list of ways to spell object names, see
|
||||
the "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
|
||||
the "SPECIFYING REVISIONS" section in linkgit:gitrevisions[1].
|
||||
|
||||
-t::
|
||||
Instead of the content, show the object type identified by
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ git imposes the following rules on how references are named:
|
|||
These rules make it easy for shell script based tools to parse
|
||||
reference names, pathname expansion by the shell when a reference name is used
|
||||
unquoted (by mistake), and also avoids ambiguities in certain
|
||||
reference name expressions (see linkgit:git-rev-parse[1]):
|
||||
reference name expressions (see linkgit:gitrevisions[1]):
|
||||
|
||||
. A double-dot `..` is often used as in `ref1..ref2`, and in some
|
||||
contexts this notation means `{caret}ref1 ref2` (i.e. not in
|
||||
|
|
|
|||
|
|
@ -20,8 +20,8 @@ OPTIONS
|
|||
-------
|
||||
<commit>...::
|
||||
Commits to cherry-pick.
|
||||
For a more complete list of ways to spell commits, see the
|
||||
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
|
||||
For a more complete list of ways to spell commits, see
|
||||
linkgit:gitrevisions[1].
|
||||
Sets of commits can be passed but no traversal is done by
|
||||
default, as if the '--no-walk' option was specified, see
|
||||
linkgit:git-rev-list[1].
|
||||
|
|
|
|||
|
|
@ -68,11 +68,11 @@ for the last two forms that use ".." notations, can be any
|
|||
<tree-ish>.
|
||||
|
||||
For a more complete list of ways to spell <commit>, see
|
||||
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
|
||||
"SPECIFYING REVISIONS" section in linkgit:gitrevisions[1].
|
||||
However, "diff" is about comparing two _endpoints_, not ranges,
|
||||
and the range notations ("<commit>..<commit>" and
|
||||
"<commit>\...<commit>") do not mean a range as defined in the
|
||||
"SPECIFYING RANGES" section in linkgit:git-rev-parse[1].
|
||||
"SPECIFYING RANGES" section in linkgit:gitrevisions[1].
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
|
|
|||
|
|
@ -439,7 +439,7 @@ Marks must be declared (via `mark`) before they can be used.
|
|||
* A complete 40 byte or abbreviated commit SHA-1 in hex.
|
||||
|
||||
* Any valid Git SHA-1 expression that resolves to a commit. See
|
||||
``SPECIFYING REVISIONS'' in linkgit:git-rev-parse[1] for details.
|
||||
``SPECIFYING REVISIONS'' in linkgit:gitrevisions[1] for details.
|
||||
|
||||
The special case of restarting an incremental import from the
|
||||
current branch value should be written as:
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ There are two ways to specify which commits to operate on.
|
|||
that leads to the <since> to be output.
|
||||
|
||||
2. Generic <revision range> expression (see "SPECIFYING
|
||||
REVISIONS" section in linkgit:git-rev-parse[1]) means the
|
||||
REVISIONS" section in linkgit:gitrevisions[1]) means the
|
||||
commits in the specified range.
|
||||
|
||||
The first rule takes precedence in the case of a single <commit>. To
|
||||
|
|
|
|||
|
|
@ -34,8 +34,7 @@ include::diff-options.txt[]
|
|||
either <since> or <until> is omitted, it defaults to
|
||||
`HEAD`, i.e. the tip of the current branch.
|
||||
For a more complete list of ways to spell <since>
|
||||
and <until>, see "SPECIFYING REVISIONS" section in
|
||||
linkgit:git-rev-parse[1].
|
||||
and <until>, see linkgit:gitrevisions[1].
|
||||
|
||||
--no-decorate::
|
||||
--decorate[=short|full|no]::
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ OPTIONS[[OPTIONS]]
|
|||
+
|
||||
The <src> is often the name of the branch you would want to push, but
|
||||
it can be any arbitrary "SHA-1 expression", such as `master~4` or
|
||||
`HEAD` (see linkgit:git-rev-parse[1]).
|
||||
`HEAD` (see linkgit:gitrevisions[1]).
|
||||
+
|
||||
The <dst> tells which ref on the remote side is updated with this
|
||||
push. Arbitrary expressions cannot be used here, an actual ref must
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ see linkgit:git-log[1].
|
|||
The reflog is useful in various git commands, to specify the old value
|
||||
of a reference. For example, `HEAD@\{2\}` means "where HEAD used to be
|
||||
two moves ago", `master@\{one.week.ago\}` means "where master used to
|
||||
point to one week ago", and so on. See linkgit:git-rev-parse[1] for
|
||||
point to one week ago", and so on. See linkgit:gitrevisions[1] for
|
||||
more details.
|
||||
|
||||
To delete single entries from the reflog, use the subcommand "delete"
|
||||
|
|
|
|||
|
|
@ -174,205 +174,7 @@ shown. If the pattern does not contain a globbing character (`?`,
|
|||
Flags and parameters to be parsed.
|
||||
|
||||
|
||||
SPECIFYING REVISIONS
|
||||
--------------------
|
||||
|
||||
A revision parameter typically, but not necessarily, names a
|
||||
commit object. They use what is called an 'extended SHA1'
|
||||
syntax. Here are various ways to spell object names. The
|
||||
ones listed near the end of this list are to name trees and
|
||||
blobs contained in a commit.
|
||||
|
||||
* The full SHA1 object name (40-byte hexadecimal string), or
|
||||
a substring of such that is unique within the repository.
|
||||
E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both
|
||||
name the same commit object if there are no other object in
|
||||
your repository whose object name starts with dae86e.
|
||||
|
||||
* An output from 'git describe'; i.e. a closest tag, optionally
|
||||
followed by a dash and a number of commits, followed by a dash, a
|
||||
`g`, and an abbreviated object name.
|
||||
|
||||
* A symbolic ref name. E.g. 'master' typically means the commit
|
||||
object referenced by refs/heads/master. If you
|
||||
happen to have both heads/master and tags/master, you can
|
||||
explicitly say 'heads/master' to tell git which one you mean.
|
||||
When ambiguous, a `<name>` is disambiguated by taking the
|
||||
first match in the following rules:
|
||||
|
||||
. if `$GIT_DIR/<name>` exists, that is what you mean (this is usually
|
||||
useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD` and `MERGE_HEAD`);
|
||||
|
||||
. otherwise, `refs/<name>` if exists;
|
||||
|
||||
. otherwise, `refs/tags/<name>` if exists;
|
||||
|
||||
. otherwise, `refs/heads/<name>` if exists;
|
||||
|
||||
. otherwise, `refs/remotes/<name>` if exists;
|
||||
|
||||
. otherwise, `refs/remotes/<name>/HEAD` if exists.
|
||||
+
|
||||
HEAD names the commit your changes in the working tree is based on.
|
||||
FETCH_HEAD records the branch you fetched from a remote repository
|
||||
with your last 'git fetch' invocation.
|
||||
ORIG_HEAD is created by commands that moves your HEAD in a drastic
|
||||
way, to record the position of the HEAD before their operation, so that
|
||||
you can change the tip of the branch back to the state before you ran
|
||||
them easily.
|
||||
MERGE_HEAD records the commit(s) you are merging into your branch
|
||||
when you run 'git merge'.
|
||||
+
|
||||
Note that any of the `refs/*` cases above may come either from
|
||||
the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file.
|
||||
|
||||
* A ref followed by the suffix '@' with a date specification
|
||||
enclosed in a brace
|
||||
pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1
|
||||
second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value
|
||||
of the ref at a prior point in time. This suffix may only be
|
||||
used immediately following a ref name and the ref must have an
|
||||
existing log ($GIT_DIR/logs/<ref>). Note that this looks up the state
|
||||
of your *local* ref at a given time; e.g., what was in your local
|
||||
`master` branch last week. If you want to look at commits made during
|
||||
certain times, see `--since` and `--until`.
|
||||
|
||||
* A ref followed by the suffix '@' with an ordinal specification
|
||||
enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify
|
||||
the n-th prior value of that ref. For example 'master@\{1\}'
|
||||
is the immediate prior value of 'master' while 'master@\{5\}'
|
||||
is the 5th prior value of 'master'. This suffix may only be used
|
||||
immediately following a ref name and the ref must have an existing
|
||||
log ($GIT_DIR/logs/<ref>).
|
||||
|
||||
* You can use the '@' construct with an empty ref part to get at a
|
||||
reflog of the current branch. For example, if you are on the
|
||||
branch 'blabla', then '@\{1\}' means the same as 'blabla@\{1\}'.
|
||||
|
||||
* The special construct '@\{-<n>\}' means the <n>th branch checked out
|
||||
before the current one.
|
||||
|
||||
* The suffix '@\{upstream\}' to a ref (short form 'ref@\{u\}') refers to
|
||||
the branch the ref is set to build on top of. Missing ref defaults
|
||||
to the current branch.
|
||||
|
||||
* A suffix '{caret}' to a revision parameter (e.g. 'HEAD{caret}') means the first parent of
|
||||
that commit object. '{caret}<n>' means the <n>th parent (i.e.
|
||||
'rev{caret}'
|
||||
is equivalent to 'rev{caret}1'). As a special rule,
|
||||
'rev{caret}0' means the commit itself and is used when 'rev' is the
|
||||
object name of a tag object that refers to a commit object.
|
||||
|
||||
* A suffix '{tilde}<n>' to a revision parameter means the commit
|
||||
object that is the <n>th generation grand-parent of the named
|
||||
commit object, following only the first parent. I.e. rev~3 is
|
||||
equivalent to rev{caret}{caret}{caret} which is equivalent to
|
||||
rev{caret}1{caret}1{caret}1. See below for a illustration of
|
||||
the usage of this form.
|
||||
|
||||
* A suffix '{caret}' followed by an object type name enclosed in
|
||||
brace pair (e.g. `v0.99.8{caret}\{commit\}`) means the object
|
||||
could be a tag, and dereference the tag recursively until an
|
||||
object of that type is found or the object cannot be
|
||||
dereferenced anymore (in which case, barf). `rev{caret}0`
|
||||
introduced earlier is a short-hand for `rev{caret}\{commit\}`.
|
||||
|
||||
* A suffix '{caret}' followed by an empty brace pair
|
||||
(e.g. `v0.99.8{caret}\{\}`) means the object could be a tag,
|
||||
and dereference the tag recursively until a non-tag object is
|
||||
found.
|
||||
|
||||
* A colon, followed by a slash, followed by a text (e.g. `:/fix nasty bug`): this names
|
||||
a commit whose commit message starts with the specified text.
|
||||
This name returns the youngest matching commit which is
|
||||
reachable from any ref. If the commit message starts with a
|
||||
'!', you have to repeat that; the special sequence ':/!',
|
||||
followed by something else than '!' is reserved for now.
|
||||
|
||||
* A suffix ':' followed by a path (e.g. `HEAD:README`); this names the blob or tree
|
||||
at the given path in the tree-ish object named by the part
|
||||
before the colon.
|
||||
':path' (with an empty part before the colon, e.g. `:README`)
|
||||
is a special case of the syntax described next: content
|
||||
recorded in the index at the given path.
|
||||
|
||||
* A colon, optionally followed by a stage number (0 to 3) and a
|
||||
colon, followed by a path (e.g. `:0:README`); this names a blob object in the
|
||||
index at the given path. Missing stage number (and the colon
|
||||
that follows it, e.g. `:README`) names a stage 0 entry. During a merge, stage
|
||||
1 is the common ancestor, stage 2 is the target branch's version
|
||||
(typically the current branch), and stage 3 is the version from
|
||||
the branch being merged.
|
||||
|
||||
Here is an illustration, by Jon Loeliger. Both commit nodes B
|
||||
and C are parents of commit node A. Parent commits are ordered
|
||||
left-to-right.
|
||||
|
||||
........................................
|
||||
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
|
||||
|
||||
|
||||
SPECIFYING RANGES
|
||||
-----------------
|
||||
|
||||
History traversing commands such as 'git log' operate on a set
|
||||
of commits, not just a single commit. To these commands,
|
||||
specifying a single revision with the notation described in the
|
||||
previous section means the set of commits reachable from that
|
||||
commit, following the commit ancestry chain.
|
||||
|
||||
To exclude commits reachable from a commit, a prefix `{caret}`
|
||||
notation is used. E.g. `{caret}r1 r2` means commits reachable
|
||||
from `r2` but exclude the ones reachable from `r1`.
|
||||
|
||||
This set operation appears so often that there is a shorthand
|
||||
for it. When you have two commits `r1` and `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 `{caret}r1 r2` and it can be written as `r1..r2`.
|
||||
|
||||
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` or `r2` but not from both.
|
||||
|
||||
Two other shorthands for naming a set that is formed by a commit
|
||||
and its parent commits exist. The `r1{caret}@` notation means all
|
||||
parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
|
||||
all of its parents.
|
||||
|
||||
Here are a handful of 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 G H D E B C
|
||||
^D B C E I J F B C
|
||||
C^@ I J F
|
||||
F^! D G H D F
|
||||
include::revisions.txt[]
|
||||
|
||||
PARSEOPT
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ OPTIONS
|
|||
<commit>...::
|
||||
Commits to revert.
|
||||
For a more complete list of ways to spell commit names, see
|
||||
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
|
||||
linkgit:gitrevisions[1].
|
||||
Sets of commits can also be given but no traversal is done by
|
||||
default, see linkgit:git-rev-list[1] and its '--no-walk'
|
||||
option.
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ no <rev> nor <glob> is given on the command line.
|
|||
OPTIONS
|
||||
-------
|
||||
<rev>::
|
||||
Arbitrary extended SHA1 expression (see linkgit:git-rev-parse[1])
|
||||
Arbitrary extended SHA1 expression (see linkgit:gitrevisions[1])
|
||||
that typically names a branch head or a tag.
|
||||
|
||||
<glob>::
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ OPTIONS
|
|||
<object>...::
|
||||
The names of objects to show.
|
||||
For a more complete list of ways to spell object names, see
|
||||
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
|
||||
"SPECIFYING REVISIONS" section in linkgit:gitrevisions[1].
|
||||
|
||||
include::pretty-options.txt[]
|
||||
|
||||
|
|
|
|||
|
|
@ -479,7 +479,7 @@ HEAD::
|
|||
(i.e. the contents of `$GIT_DIR/refs/heads/<head>`).
|
||||
|
||||
For a more complete list of ways to spell object names, see
|
||||
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
|
||||
"SPECIFYING REVISIONS" section in linkgit:gitrevisions[1].
|
||||
|
||||
|
||||
File/Directory Structure
|
||||
|
|
|
|||
|
|
@ -971,7 +971,7 @@ commits from the master branch. The string inside brackets
|
|||
before the commit log message is a short name you can use to
|
||||
name the commit. In the above example, 'master' and 'mybranch'
|
||||
are branch heads. 'master^' is the first parent of 'master'
|
||||
branch head. Please see linkgit:git-rev-parse[1] if you want to
|
||||
branch head. Please see linkgit:gitrevisions[1] if you want to
|
||||
see more complex cases.
|
||||
|
||||
[NOTE]
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ frequently used options.
|
|||
the form "'<from>'..'<to>'" to show all revisions between '<from>' and
|
||||
back to '<to>'. Note, more advanced revision selection can be applied.
|
||||
For a more complete list of ways to spell object names, see
|
||||
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
|
||||
linkgit:gitrevisions[1].
|
||||
|
||||
<path>...::
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,35 @@
|
|||
gitrevisions(7)
|
||||
================
|
||||
|
||||
NAME
|
||||
----
|
||||
gitrevisions - specifying revisions and ranges for git
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
gitrevisions
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
Many Git commands take revision parameters as arguments. Depending on
|
||||
the command, they denote a specific commit or, for commands which
|
||||
walk the revision graph (such as linkgit:git-log[1]), all commits which can
|
||||
be reached from that commit. In the latter case one can also specify a
|
||||
range of revisions explicitly.
|
||||
|
||||
In addition, some Git commands (such as linkgit:git-show[1]) also take
|
||||
revision parameters which denote other objects than commits, e.g. blobs
|
||||
("files") or trees ("directories of files").
|
||||
|
||||
include::revisions.txt[]
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
linkgit:git-rev-parse[1]
|
||||
|
||||
GIT
|
||||
---
|
||||
Part of the linkgit:git[1] suite
|
||||
|
|
@ -0,0 +1,199 @@
|
|||
SPECIFYING REVISIONS
|
||||
--------------------
|
||||
|
||||
A revision parameter typically, but not necessarily, names a
|
||||
commit object. They use what is called an 'extended SHA1'
|
||||
syntax. Here are various ways to spell object names. The
|
||||
ones listed near the end of this list are to name trees and
|
||||
blobs contained in a commit.
|
||||
|
||||
* The full SHA1 object name (40-byte hexadecimal string), or
|
||||
a substring of such that is unique within the repository.
|
||||
E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both
|
||||
name the same commit object if there are no other object in
|
||||
your repository whose object name starts with dae86e.
|
||||
|
||||
* An output from 'git describe'; i.e. a closest tag, optionally
|
||||
followed by a dash and a number of commits, followed by a dash, a
|
||||
`g`, and an abbreviated object name.
|
||||
|
||||
* A symbolic ref name. E.g. 'master' typically means the commit
|
||||
object referenced by refs/heads/master. If you
|
||||
happen to have both heads/master and tags/master, you can
|
||||
explicitly say 'heads/master' to tell git which one you mean.
|
||||
When ambiguous, a `<name>` is disambiguated by taking the
|
||||
first match in the following rules:
|
||||
|
||||
. if `$GIT_DIR/<name>` exists, that is what you mean (this is usually
|
||||
useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD` and `MERGE_HEAD`);
|
||||
|
||||
. otherwise, `refs/<name>` if exists;
|
||||
|
||||
. otherwise, `refs/tags/<name>` if exists;
|
||||
|
||||
. otherwise, `refs/heads/<name>` if exists;
|
||||
|
||||
. otherwise, `refs/remotes/<name>` if exists;
|
||||
|
||||
. otherwise, `refs/remotes/<name>/HEAD` if exists.
|
||||
+
|
||||
HEAD names the commit your changes in the working tree is based on.
|
||||
FETCH_HEAD records the branch you fetched from a remote repository
|
||||
with your last 'git fetch' invocation.
|
||||
ORIG_HEAD is created by commands that moves your HEAD in a drastic
|
||||
way, to record the position of the HEAD before their operation, so that
|
||||
you can change the tip of the branch back to the state before you ran
|
||||
them easily.
|
||||
MERGE_HEAD records the commit(s) you are merging into your branch
|
||||
when you run 'git merge'.
|
||||
+
|
||||
Note that any of the `refs/*` cases above may come either from
|
||||
the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file.
|
||||
|
||||
* A ref followed by the suffix '@' with a date specification
|
||||
enclosed in a brace
|
||||
pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1
|
||||
second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value
|
||||
of the ref at a prior point in time. This suffix may only be
|
||||
used immediately following a ref name and the ref must have an
|
||||
existing log ($GIT_DIR/logs/<ref>). Note that this looks up the state
|
||||
of your *local* ref at a given time; e.g., what was in your local
|
||||
`master` branch last week. If you want to look at commits made during
|
||||
certain times, see `--since` and `--until`.
|
||||
|
||||
* A ref followed by the suffix '@' with an ordinal specification
|
||||
enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify
|
||||
the n-th prior value of that ref. For example 'master@\{1\}'
|
||||
is the immediate prior value of 'master' while 'master@\{5\}'
|
||||
is the 5th prior value of 'master'. This suffix may only be used
|
||||
immediately following a ref name and the ref must have an existing
|
||||
log ($GIT_DIR/logs/<ref>).
|
||||
|
||||
* You can use the '@' construct with an empty ref part to get at a
|
||||
reflog of the current branch. For example, if you are on the
|
||||
branch 'blabla', then '@\{1\}' means the same as 'blabla@\{1\}'.
|
||||
|
||||
* The special construct '@\{-<n>\}' means the <n>th branch checked out
|
||||
before the current one.
|
||||
|
||||
* The suffix '@\{upstream\}' to a ref (short form 'ref@\{u\}') refers to
|
||||
the branch the ref is set to build on top of. Missing ref defaults
|
||||
to the current branch.
|
||||
|
||||
* A suffix '{caret}' to a revision parameter (e.g. 'HEAD{caret}') means the first parent of
|
||||
that commit object. '{caret}<n>' means the <n>th parent (i.e.
|
||||
'rev{caret}'
|
||||
is equivalent to 'rev{caret}1'). As a special rule,
|
||||
'rev{caret}0' means the commit itself and is used when 'rev' is the
|
||||
object name of a tag object that refers to a commit object.
|
||||
|
||||
* A suffix '{tilde}<n>' to a revision parameter means the commit
|
||||
object that is the <n>th generation grand-parent of the named
|
||||
commit object, following only the first parent. I.e. rev~3 is
|
||||
equivalent to rev{caret}{caret}{caret} which is equivalent to
|
||||
rev{caret}1{caret}1{caret}1. See below for a illustration of
|
||||
the usage of this form.
|
||||
|
||||
* A suffix '{caret}' followed by an object type name enclosed in
|
||||
brace pair (e.g. `v0.99.8{caret}\{commit\}`) means the object
|
||||
could be a tag, and dereference the tag recursively until an
|
||||
object of that type is found or the object cannot be
|
||||
dereferenced anymore (in which case, barf). `rev{caret}0`
|
||||
introduced earlier is a short-hand for `rev{caret}\{commit\}`.
|
||||
|
||||
* A suffix '{caret}' followed by an empty brace pair
|
||||
(e.g. `v0.99.8{caret}\{\}`) means the object could be a tag,
|
||||
and dereference the tag recursively until a non-tag object is
|
||||
found.
|
||||
|
||||
* A colon, followed by a slash, followed by a text (e.g. `:/fix nasty bug`): this names
|
||||
a commit whose commit message starts with the specified text.
|
||||
This name returns the youngest matching commit which is
|
||||
reachable from any ref. If the commit message starts with a
|
||||
'!', you have to repeat that; the special sequence ':/!',
|
||||
followed by something else than '!' is reserved for now.
|
||||
|
||||
* A suffix ':' followed by a path (e.g. `HEAD:README`); this names the blob or tree
|
||||
at the given path in the tree-ish object named by the part
|
||||
before the colon.
|
||||
':path' (with an empty part before the colon, e.g. `:README`)
|
||||
is a special case of the syntax described next: content
|
||||
recorded in the index at the given path.
|
||||
|
||||
* A colon, optionally followed by a stage number (0 to 3) and a
|
||||
colon, followed by a path (e.g. `:0:README`); this names a blob object in the
|
||||
index at the given path. Missing stage number (and the colon
|
||||
that follows it, e.g. `:README`) names a stage 0 entry. During a merge, stage
|
||||
1 is the common ancestor, stage 2 is the target branch's version
|
||||
(typically the current branch), and stage 3 is the version from
|
||||
the branch being merged.
|
||||
|
||||
Here is an illustration, by Jon Loeliger. Both commit nodes B
|
||||
and C are parents of commit node A. Parent commits are ordered
|
||||
left-to-right.
|
||||
|
||||
........................................
|
||||
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
|
||||
|
||||
|
||||
SPECIFYING RANGES
|
||||
-----------------
|
||||
|
||||
History traversing commands such as 'git log' operate on a set
|
||||
of commits, not just a single commit. To these commands,
|
||||
specifying a single revision with the notation described in the
|
||||
previous section means the set of commits reachable from that
|
||||
commit, following the commit ancestry chain.
|
||||
|
||||
To exclude commits reachable from a commit, a prefix `{caret}`
|
||||
notation is used. E.g. `{caret}r1 r2` means commits reachable
|
||||
from `r2` but exclude the ones reachable from `r1`.
|
||||
|
||||
This set operation appears so often that there is a shorthand
|
||||
for it. When you have two commits `r1` and `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 `{caret}r1 r2` and it can be written as `r1..r2`.
|
||||
|
||||
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` or `r2` but not from both.
|
||||
|
||||
Two other shorthands for naming a set that is formed by a commit
|
||||
and its parent commits exist. The `r1{caret}@` notation means all
|
||||
parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
|
||||
all of its parents.
|
||||
|
||||
Here are a handful of 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 G H D E B C
|
||||
^D B C E I J F B C
|
||||
C^@ I J F
|
||||
F^! D G H D F
|
||||
|
|
@ -397,7 +397,7 @@ is usually a shortcut for the HEAD branch in the repository "origin".
|
|||
For the complete list of paths which git checks for references, and
|
||||
the order it uses to decide which to choose when there are multiple
|
||||
references with the same shorthand name, see the "SPECIFYING
|
||||
REVISIONS" section of linkgit:git-rev-parse[1].
|
||||
REVISIONS" section of linkgit:gitrevisions[1].
|
||||
|
||||
[[Updating-a-repository-With-git-fetch]]
|
||||
Updating a repository with git fetch
|
||||
|
|
@ -568,7 +568,7 @@ We have seen several ways of naming commits already:
|
|||
- HEAD: refers to the head of the current branch
|
||||
|
||||
There are many more; see the "SPECIFYING REVISIONS" section of the
|
||||
linkgit:git-rev-parse[1] man page for the complete list of ways to
|
||||
linkgit:gitrevisions[1] man page for the complete list of ways to
|
||||
name revisions. Some examples:
|
||||
|
||||
-------------------------------------------------
|
||||
|
|
@ -909,7 +909,7 @@ commits reachable from some head but not from any tag in the repository:
|
|||
$ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
|
||||
-------------------------------------------------
|
||||
|
||||
(See linkgit:git-rev-parse[1] for explanations of commit-selecting
|
||||
(See linkgit:gitrevisions[1] for explanations of commit-selecting
|
||||
syntax such as `--not`.)
|
||||
|
||||
[[making-a-release]]
|
||||
|
|
@ -1635,7 +1635,7 @@ you've checked out.
|
|||
The reflogs are kept by default for 30 days, after which they may be
|
||||
pruned. See linkgit:git-reflog[1] and linkgit:git-gc[1] to learn
|
||||
how to control this pruning, and see the "SPECIFYING REVISIONS"
|
||||
section of linkgit:git-rev-parse[1] for details.
|
||||
section of linkgit:gitrevisions[1] for details.
|
||||
|
||||
Note that the reflog history is very different from normal git history.
|
||||
While normal history is shared by every repository that works on the
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче