Merge branch 'dm/maint-docco'
* dm/maint-docco: Documentation: Remove spurious uses of "you" in git-bisect.txt. Documentation: minor grammatical fix in git-check-ref-format.txt Documentation: minor grammatical fixes in git-check-attr.txt Documentation: minor grammatical fixes in git-cat-file.txt Documentation: minor grammatical fixes and rewording in git-bundle.txt Documentation: remove some uses of the passive voice in git-bisect.txt
This commit is contained in:
commit
0b3035fe15
@ -81,7 +81,7 @@ will have been left with the first bad kernel revision in "refs/bisect/bad".
|
|||||||
Bisect reset
|
Bisect reset
|
||||||
~~~~~~~~~~~~
|
~~~~~~~~~~~~
|
||||||
|
|
||||||
To return to the original head after a bisect session, you issue the
|
To return to the original head after a bisect session, issue the
|
||||||
following command:
|
following command:
|
||||||
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
@ -95,8 +95,8 @@ the bisection state).
|
|||||||
Bisect visualize
|
Bisect visualize
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
To see the currently remaining suspects in 'gitk', the following command
|
To see the currently remaining suspects in 'gitk', issue the following
|
||||||
is issued during the bisection process:
|
command during the bisection process:
|
||||||
|
|
||||||
------------
|
------------
|
||||||
$ git bisect visualize
|
$ git bisect visualize
|
||||||
@ -115,7 +115,7 @@ $ git bisect view --stat
|
|||||||
Bisect log and bisect replay
|
Bisect log and bisect replay
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
After having marked revisions as good or bad, you issue the following
|
After having marked revisions as good or bad, issue the following
|
||||||
command to show what has been done so far:
|
command to show what has been done so far:
|
||||||
|
|
||||||
------------
|
------------
|
||||||
@ -135,7 +135,7 @@ $ git bisect replay that-file
|
|||||||
Avoiding testing a commit
|
Avoiding testing a commit
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
If in the middle of a bisect session, you know that the next suggested
|
If, in the middle of a bisect session, you know that the next suggested
|
||||||
revision is not a good one to test (e.g. the change the commit
|
revision is not a good one to test (e.g. the change the commit
|
||||||
introduces is known not to work in your environment and you know it
|
introduces is known not to work in your environment and you know it
|
||||||
does not have anything to do with the bug you are chasing), you may
|
does not have anything to do with the bug you are chasing), you may
|
||||||
@ -151,8 +151,8 @@ $ git reset --hard HEAD~3 # try 3 revisions before what
|
|||||||
# was suggested
|
# was suggested
|
||||||
------------
|
------------
|
||||||
|
|
||||||
Then compile and test the chosen revision. Afterwards the revision
|
Then compile and test the chosen revision, and afterwards mark
|
||||||
is marked as good or bad in the usual manner.
|
the revision as good or bad in the usual manner.
|
||||||
|
|
||||||
Bisect skip
|
Bisect skip
|
||||||
~~~~~~~~~~~~
|
~~~~~~~~~~~~
|
||||||
@ -175,8 +175,8 @@ using the "'<commit1>'..'<commit2>'" notation. For example:
|
|||||||
$ git bisect skip v2.5..v2.6
|
$ git bisect skip v2.5..v2.6
|
||||||
------------
|
------------
|
||||||
|
|
||||||
The effect of this would be that no commit between `v2.5` excluded and
|
This tells the bisect process that no commit after `v2.5`, up to and
|
||||||
`v2.6` included could be tested.
|
including `v2.6`, should be tested.
|
||||||
|
|
||||||
Note that if you also want to skip the first commit of the range you
|
Note that if you also want to skip the first commit of the range you
|
||||||
would issue the command:
|
would issue the command:
|
||||||
@ -185,8 +185,8 @@ would issue the command:
|
|||||||
$ git bisect skip v2.5 v2.5..v2.6
|
$ git bisect skip v2.5 v2.5..v2.6
|
||||||
------------
|
------------
|
||||||
|
|
||||||
This would cause the commits between `v2.5` included and `v2.6` included
|
This tells the bisect process that the commits between `v2.5` included
|
||||||
to be skipped.
|
and `v2.6` included should be skipped.
|
||||||
|
|
||||||
|
|
||||||
Cutting down bisection by giving more parameters to bisect start
|
Cutting down bisection by giving more parameters to bisect start
|
||||||
|
@ -19,13 +19,13 @@ DESCRIPTION
|
|||||||
|
|
||||||
Some workflows require that one or more branches of development on one
|
Some workflows require that one or more branches of development on one
|
||||||
machine be replicated on another machine, but the two machines cannot
|
machine be replicated on another machine, but the two machines cannot
|
||||||
be directly connected so the interactive git protocols (git, ssh,
|
be directly connected, and therefore the interactive git protocols (git,
|
||||||
rsync, http) cannot be used. This command provides support for
|
ssh, rsync, http) cannot be used. This command provides support for
|
||||||
'git-fetch' and 'git-pull' to operate by packaging objects and references
|
'git-fetch' and 'git-pull' to operate by packaging objects and references
|
||||||
in an archive at the originating machine, then importing those into
|
in an archive at the originating machine, then importing those into
|
||||||
another repository using 'git-fetch' and 'git-pull'
|
another repository using 'git-fetch' and 'git-pull'
|
||||||
after moving the archive by some means (i.e., by sneakernet). As no
|
after moving the archive by some means (i.e., by sneakernet). As no
|
||||||
direct connection between repositories exists, the user must specify a
|
direct connection between the repositories exists, the user must specify a
|
||||||
basis for the bundle that is held by the destination repository: the
|
basis for the bundle that is held by the destination repository: the
|
||||||
bundle assumes that all objects in the basis are already in the
|
bundle assumes that all objects in the basis are already in the
|
||||||
destination repository.
|
destination repository.
|
||||||
@ -43,7 +43,7 @@ verify <file>::
|
|||||||
bundle format itself as well as checking that the prerequisite
|
bundle format itself as well as checking that the prerequisite
|
||||||
commits exist and are fully linked in the current repository.
|
commits exist and are fully linked in the current repository.
|
||||||
'git-bundle' prints a list of missing commits, if any, and exits
|
'git-bundle' prints a list of missing commits, if any, and exits
|
||||||
with non-zero status.
|
with a non-zero status.
|
||||||
|
|
||||||
list-heads <file>::
|
list-heads <file>::
|
||||||
Lists the references defined in the bundle. If followed by a
|
Lists the references defined in the bundle. If followed by a
|
||||||
@ -53,14 +53,14 @@ list-heads <file>::
|
|||||||
unbundle <file>::
|
unbundle <file>::
|
||||||
Passes the objects in the bundle to 'git-index-pack'
|
Passes the objects in the bundle to 'git-index-pack'
|
||||||
for storage in the repository, then prints the names of all
|
for storage in the repository, then prints the names of all
|
||||||
defined references. If a reflist is given, only references
|
defined references. If a list of references is given, only
|
||||||
matching those in the given list are printed. This command is
|
references matching those in the list are printed. This command is
|
||||||
really plumbing, intended to be called only by 'git-fetch'.
|
really plumbing, intended to be called only by 'git-fetch'.
|
||||||
|
|
||||||
[git-rev-list-args...]::
|
[git-rev-list-args...]::
|
||||||
A list of arguments, acceptable to 'git-rev-parse' and
|
A list of arguments, acceptable to 'git-rev-parse' and
|
||||||
'git-rev-list', that specify the specific objects and references
|
'git-rev-list', that specifies the specific objects and references
|
||||||
to transport. For example, "master~10..master" causes the
|
to transport. For example, `master\~10..master` causes the
|
||||||
current master reference to be packaged along with all objects
|
current master reference to be packaged along with all objects
|
||||||
added since its 10th ancestor commit. There is no explicit
|
added since its 10th ancestor commit. There is no explicit
|
||||||
limit to the number of references and objects that may be
|
limit to the number of references and objects that may be
|
||||||
@ -71,24 +71,24 @@ unbundle <file>::
|
|||||||
A list of references used to limit the references reported as
|
A list of references used to limit the references reported as
|
||||||
available. This is principally of use to 'git-fetch', which
|
available. This is principally of use to 'git-fetch', which
|
||||||
expects to receive only those references asked for and not
|
expects to receive only those references asked for and not
|
||||||
necessarily everything in the pack (in this case, 'git-bundle' is
|
necessarily everything in the pack (in this case, 'git-bundle' acts
|
||||||
acting like 'git-fetch-pack').
|
like 'git-fetch-pack').
|
||||||
|
|
||||||
SPECIFYING REFERENCES
|
SPECIFYING REFERENCES
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
'git-bundle' will only package references that are shown by
|
'git-bundle' will only package references that are shown by
|
||||||
'git-show-ref': this includes heads, tags, and remote heads. References
|
'git-show-ref': this includes heads, tags, and remote heads. References
|
||||||
such as master~1 cannot be packaged, but are perfectly suitable for
|
such as `master\~1` cannot be packaged, but are perfectly suitable for
|
||||||
defining the basis. More than one reference may be packaged, and more
|
defining the basis. More than one reference may be packaged, and more
|
||||||
than one basis can be specified. The objects packaged are those not
|
than one basis can be specified. The objects packaged are those not
|
||||||
contained in the union of the given bases. Each basis can be
|
contained in the union of the given bases. Each basis can be
|
||||||
specified explicitly (e.g., ^master~10), or implicitly (e.g.,
|
specified explicitly (e.g. `^master\~10`), or implicitly (e.g.
|
||||||
master~10..master, --since=10.days.ago master).
|
`master\~10..master`, `--since=10.days.ago master`).
|
||||||
|
|
||||||
It is very important that the basis used be held by the destination.
|
It is very important that the basis used be held by the destination.
|
||||||
It is okay to err on the side of conservatism, causing the bundle file
|
It is okay to err on the side of caution, causing the bundle file
|
||||||
to contain objects already in the destination as these are ignored
|
to contain objects already in the destination, as these are ignored
|
||||||
when unpacking at the destination.
|
when unpacking at the destination.
|
||||||
|
|
||||||
EXAMPLE
|
EXAMPLE
|
||||||
@ -97,13 +97,13 @@ EXAMPLE
|
|||||||
Assume you want to transfer the history from a repository R1 on machine A
|
Assume you want to transfer the history from a repository R1 on machine A
|
||||||
to another repository R2 on machine B.
|
to another repository R2 on machine B.
|
||||||
For whatever reason, direct connection between A and B is not allowed,
|
For whatever reason, direct connection between A and B is not allowed,
|
||||||
but we can move data from A to B via some mechanism (CD, email, etc).
|
but we can move data from A to B via some mechanism (CD, email, etc.).
|
||||||
We want to update R2 with developments made on branch master in R1.
|
We want to update R2 with development made on the branch master in R1.
|
||||||
|
|
||||||
To bootstrap the process, you can first create a bundle that doesn't have
|
To bootstrap the process, you can first create a bundle that does not have
|
||||||
any basis. You can use a tag to remember up to what commit you sent out
|
any basis. You can use a tag to remember up to what commit you last
|
||||||
in order to make it easy to later update the other repository with
|
processed, in order to make it easy to later update the other repository
|
||||||
incremental bundle,
|
with an incremental bundle:
|
||||||
|
|
||||||
----------------
|
----------------
|
||||||
machineA$ cd R1
|
machineA$ cd R1
|
||||||
@ -111,17 +111,17 @@ machineA$ git bundle create file.bundle master
|
|||||||
machineA$ git tag -f lastR2bundle master
|
machineA$ git tag -f lastR2bundle master
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
Then you sneakernet file.bundle to the target machine B. Because you don't
|
Then you transfer file.bundle to the target machine B. If you are creating
|
||||||
have to have any object to extract objects from such a bundle, not only
|
the repository on machine B, then you can clone from the bundle as if it
|
||||||
you can fetch/pull from a bundle, you can clone from it as if it was a
|
were a remote repository instead of creating an empty repository and then
|
||||||
remote repository.
|
pulling or fetching objects from the bundle:
|
||||||
|
|
||||||
----------------
|
----------------
|
||||||
machineB$ git clone /home/me/tmp/file.bundle R2
|
machineB$ git clone /home/me/tmp/file.bundle R2
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
This will define a remote called "origin" in the resulting repository that
|
This will define a remote called "origin" in the resulting repository that
|
||||||
lets you fetch and pull from the bundle. $GIT_DIR/config file in R2 may
|
lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will
|
||||||
have an entry like this:
|
have an entry like this:
|
||||||
|
|
||||||
------------------------
|
------------------------
|
||||||
@ -130,12 +130,12 @@ have an entry like this:
|
|||||||
fetch = refs/heads/*:refs/remotes/origin/*
|
fetch = refs/heads/*:refs/remotes/origin/*
|
||||||
------------------------
|
------------------------
|
||||||
|
|
||||||
You can fetch/pull to update the resulting mine.git repository after
|
To update the resulting mine.git repository, you can fetch or pull after
|
||||||
replacing the bundle you store at /home/me/tmp/file.bundle with incremental
|
replacing the bundle stored at /home/me/tmp/file.bundle with incremental
|
||||||
updates from here on.
|
updates.
|
||||||
|
|
||||||
After working more in the original repository, you can create an
|
After working some more in the original repository, you can create an
|
||||||
incremental bundle to update the other:
|
incremental bundle to update the other repository:
|
||||||
|
|
||||||
----------------
|
----------------
|
||||||
machineA$ cd R1
|
machineA$ cd R1
|
||||||
@ -143,8 +143,8 @@ machineA$ git bundle create file.bundle lastR2bundle..master
|
|||||||
machineA$ git tag -f lastR2bundle master
|
machineA$ git tag -f lastR2bundle master
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
and sneakernet it to the other machine to replace /home/me/tmp/file.bundle,
|
You then transfer the bundle to the other machine to replace
|
||||||
and pull from it.
|
/home/me/tmp/file.bundle, and pull from it.
|
||||||
|
|
||||||
----------------
|
----------------
|
||||||
machineB$ cd R2
|
machineB$ cd R2
|
||||||
@ -152,49 +152,49 @@ machineB$ git pull
|
|||||||
----------------
|
----------------
|
||||||
|
|
||||||
If you know up to what commit the intended recipient repository should
|
If you know up to what commit the intended recipient repository should
|
||||||
have the necessary objects for, you can use that knowledge to specify the
|
have the necessary objects, you can use that knowledge to specify the
|
||||||
basis, giving a cut-off point to limit the revisions and objects that go
|
basis, giving a cut-off point to limit the revisions and objects that go
|
||||||
in the resulting bundle. The previous example used lastR2bundle tag
|
in the resulting bundle. The previous example used lastR2bundle tag
|
||||||
for this purpose, but you can use other options you would give to
|
for this purpose, but you can use any other options that you would give to
|
||||||
the linkgit:git-log[1] command. Here are more examples:
|
the linkgit:git-log[1] command. Here are more examples:
|
||||||
|
|
||||||
You can use a tag that is present in both.
|
You can use a tag that is present in both:
|
||||||
|
|
||||||
----------------
|
----------------
|
||||||
$ git bundle create mybundle v1.0.0..master
|
$ git bundle create mybundle v1.0.0..master
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
You can use a basis based on time.
|
You can use a basis based on time:
|
||||||
|
|
||||||
----------------
|
----------------
|
||||||
$ git bundle create mybundle --since=10.days master
|
$ git bundle create mybundle --since=10.days master
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
Or you can use the number of commits.
|
You can use the number of commits:
|
||||||
|
|
||||||
----------------
|
----------------
|
||||||
$ git bundle create mybundle -10 master
|
$ git bundle create mybundle -10 master
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
You can run `git-bundle verify` to see if you can extract from a bundle
|
You can run `git-bundle verify` to see if you can extract from a bundle
|
||||||
that was created with a basis.
|
that was created with a basis:
|
||||||
|
|
||||||
----------------
|
----------------
|
||||||
$ git bundle verify mybundle
|
$ git bundle verify mybundle
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
This will list what commits you must have in order to extract from the
|
This will list what commits you must have in order to extract from the
|
||||||
bundle and will error out if you don't have them.
|
bundle and will error out if you do not have them.
|
||||||
|
|
||||||
A bundle from a recipient repository's point of view is just like a
|
A bundle from a recipient repository's point of view is just like a
|
||||||
regular repository it fetches/pulls from. You can for example map
|
regular repository which it fetches or pulls from. You can, for example, map
|
||||||
refs, like this example, when fetching:
|
references when fetching:
|
||||||
|
|
||||||
----------------
|
----------------
|
||||||
$ git fetch mybundle master:localRef
|
$ git fetch mybundle master:localRef
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
Or see what refs it offers.
|
You can also see what references it offers.
|
||||||
|
|
||||||
----------------
|
----------------
|
||||||
$ git ls-remote mybundle
|
$ git ls-remote mybundle
|
||||||
|
@ -3,7 +3,7 @@ git-cat-file(1)
|
|||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-cat-file - Provide content or type/size information for repository objects
|
git-cat-file - Provide content or type and size information for repository objects
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
@ -14,19 +14,19 @@ SYNOPSIS
|
|||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
In the first form, provides content or type of objects in the repository. The
|
In its first form, the command provides the content or the type of an object in
|
||||||
type is required unless '-t' or '-p' is used to find the object type, or '-s'
|
the repository. The type is required unless '-t' or '-p' is used to find the
|
||||||
is used to find the object size.
|
object type, or '-s' is used to find the object size.
|
||||||
|
|
||||||
In the second form, a list of object (separated by LFs) is provided on stdin,
|
In the second form, a list of objects (separated by linefeeds) is provided on
|
||||||
and the SHA1, type, and size of each object is printed on stdout.
|
stdin, and the SHA1, type, and size of each object is printed on stdout.
|
||||||
|
|
||||||
OPTIONS
|
OPTIONS
|
||||||
-------
|
-------
|
||||||
<object>::
|
<object>::
|
||||||
The name of the object to show.
|
The name of the object to show.
|
||||||
For a more complete list of ways to spell object names, see
|
For a more complete list of ways to spell object names, see
|
||||||
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
|
the "SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
|
||||||
|
|
||||||
-t::
|
-t::
|
||||||
Instead of the content, show the object type identified by
|
Instead of the content, show the object type identified by
|
||||||
@ -56,8 +56,8 @@ OPTIONS
|
|||||||
stdin. May not be combined with any other options or arguments.
|
stdin. May not be combined with any other options or arguments.
|
||||||
|
|
||||||
--batch-check::
|
--batch-check::
|
||||||
Print the SHA1, type, and size of each object provided on stdin. May not be
|
Print the SHA1, type, and size of each object provided on stdin. May not
|
||||||
combined with any other options or arguments.
|
be combined with any other options or arguments.
|
||||||
|
|
||||||
OUTPUT
|
OUTPUT
|
||||||
------
|
------
|
||||||
|
@ -14,7 +14,7 @@ SYNOPSIS
|
|||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
For every pathname, this command will list if each attr is 'unspecified',
|
For every pathname, this command will list if each attribute is 'unspecified',
|
||||||
'set', or 'unset' as a gitattribute on that pathname.
|
'set', or 'unset' as a gitattribute on that pathname.
|
||||||
|
|
||||||
OPTIONS
|
OPTIONS
|
||||||
@ -23,11 +23,11 @@ OPTIONS
|
|||||||
Read file names from stdin instead of from the command-line.
|
Read file names from stdin instead of from the command-line.
|
||||||
|
|
||||||
-z::
|
-z::
|
||||||
Only meaningful with `--stdin`; paths are separated with
|
Only meaningful with `--stdin`; paths are separated with a
|
||||||
NUL character instead of LF.
|
NUL character instead of a linefeed character.
|
||||||
|
|
||||||
\--::
|
\--::
|
||||||
Interpret all preceding arguments as attributes, and all following
|
Interpret all preceding arguments as attributes and all following
|
||||||
arguments as path names. If not supplied, only the first argument will
|
arguments as path names. If not supplied, only the first argument will
|
||||||
be treated as an attribute.
|
be treated as an attribute.
|
||||||
|
|
||||||
@ -37,12 +37,12 @@ OUTPUT
|
|||||||
The output is of the form:
|
The output is of the form:
|
||||||
<path> COLON SP <attribute> COLON SP <info> LF
|
<path> COLON SP <attribute> COLON SP <info> LF
|
||||||
|
|
||||||
Where <path> is the path of a file being queried, <attribute> is an attribute
|
<path> is the path of a file being queried, <attribute> is an attribute
|
||||||
being queried and <info> can be either:
|
being queried and <info> can be either:
|
||||||
|
|
||||||
'unspecified';; when the attribute is not defined for the path.
|
'unspecified';; when the attribute is not defined for the path.
|
||||||
'unset';; when the attribute is defined to false.
|
'unset';; when the attribute is defined as false.
|
||||||
'set';; when the attribute is defined to true.
|
'set';; when the attribute is defined as true.
|
||||||
<value>;; when a value has been assigned to the attribute.
|
<value>;; when a value has been assigned to the attribute.
|
||||||
|
|
||||||
EXAMPLES
|
EXAMPLES
|
||||||
@ -69,7 +69,7 @@ org/example/MyClass.java: diff: java
|
|||||||
org/example/MyClass.java: myAttr: set
|
org/example/MyClass.java: myAttr: set
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
* Listing attribute for multiple files:
|
* Listing an attribute for multiple files:
|
||||||
---------------
|
---------------
|
||||||
$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java
|
$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java
|
||||||
org/example/MyClass.java: myAttr: set
|
org/example/MyClass.java: myAttr: set
|
||||||
|
@ -3,7 +3,7 @@ git-check-ref-format(1)
|
|||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-check-ref-format - Make sure ref name is well formed
|
git-check-ref-format - Ensures that a reference name is well formed
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
@ -11,40 +11,40 @@ SYNOPSIS
|
|||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
Checks if a given 'refname' is acceptable, and exits non-zero if
|
Checks if a given 'refname' is acceptable, and exits with a non-zero
|
||||||
it is not.
|
status if it is not.
|
||||||
|
|
||||||
A reference is used in git to specify branches and tags. A
|
A reference is used in git to specify branches and tags. A
|
||||||
branch head is stored under `$GIT_DIR/refs/heads` directory, and
|
branch head is stored under the `$GIT_DIR/refs/heads` directory, and
|
||||||
a tag is stored under `$GIT_DIR/refs/tags` directory. git
|
a tag is stored under the `$GIT_DIR/refs/tags` directory. git
|
||||||
imposes the following rules on how refs are named:
|
imposes the following rules on how references are named:
|
||||||
|
|
||||||
. It can include slash `/` for hierarchical (directory)
|
. They can include slash `/` for hierarchical (directory)
|
||||||
grouping, but no slash-separated component can begin with a
|
grouping, but no slash-separated component can begin with a
|
||||||
dot `.`;
|
dot `.`.
|
||||||
|
|
||||||
. It cannot have two consecutive dots `..` anywhere;
|
. They cannot have two consecutive dots `..` anywhere.
|
||||||
|
|
||||||
. It cannot have ASCII control character (i.e. bytes whose
|
. They cannot have ASCII control characters (i.e. bytes whose
|
||||||
values are lower than \040, or \177 `DEL`), space, tilde `~`,
|
values are lower than \040, or \177 `DEL`), space, tilde `~`,
|
||||||
caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
|
caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
|
||||||
or open bracket `[` anywhere;
|
or open bracket `[` anywhere.
|
||||||
|
|
||||||
. It cannot end with a slash `/`.
|
. They cannot end with a slash `/`.
|
||||||
|
|
||||||
These rules makes it easy for shell script based tools to parse
|
These rules make it easy for shell script based tools to parse
|
||||||
refnames, pathname expansion by the shell when a refname is used
|
reference names, pathname expansion by the shell when a reference name is used
|
||||||
unquoted (by mistake), and also avoids ambiguities in certain
|
unquoted (by mistake), and also avoids ambiguities in certain
|
||||||
refname expressions (see linkgit:git-rev-parse[1]). Namely:
|
reference name expressions (see linkgit:git-rev-parse[1]):
|
||||||
|
|
||||||
. double-dot `..` are often used as in `ref1..ref2`, and in some
|
. A double-dot `..` is often used as in `ref1..ref2`, and in some
|
||||||
context this notation means `{caret}ref1 ref2` (i.e. not in
|
contexts this notation means `{caret}ref1 ref2` (i.e. not in
|
||||||
ref1 and in ref2).
|
`ref1` and in `ref2`).
|
||||||
|
|
||||||
. tilde `~` and caret `{caret}` are used to introduce postfix
|
. A tilde `~` and caret `{caret}` are used to introduce the postfix
|
||||||
'nth parent' and 'peel onion' operation.
|
'nth parent' and 'peel onion' operation.
|
||||||
|
|
||||||
. colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
|
. A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
|
||||||
value and store it in dstref" in fetch and push operations.
|
value and store it in dstref" in fetch and push operations.
|
||||||
It may also be used to select a specific object such as with
|
It may also be used to select a specific object such as with
|
||||||
'git-cat-file': "git cat-file blob v1.3.3:refs.c".
|
'git-cat-file': "git cat-file blob v1.3.3:refs.c".
|
||||||
|
Loading…
Reference in New Issue
Block a user