Merge branch 'maint'

* maint:
  docs: don't talk about $GIT_DIR/refs/ everywhere
This commit is contained in:
Junio C Hamano 2010-02-17 23:03:46 -08:00
commit b56735e797
10 changed files with 39 additions and 36 deletions

View file

@ -19,8 +19,9 @@ status if it is not.
A reference is used in git to specify branches and tags. A
branch head is stored under the `$GIT_DIR/refs/heads` directory, and
a tag is stored under the `$GIT_DIR/refs/tags` directory. git
imposes the following rules on how references are named:
a tag is stored under the `$GIT_DIR/refs/tags` directory (or, if refs
are packed by `git gc`, as entries in the `$GIT_DIR/packed-refs` file).
git imposes the following rules on how references are named:
. They can include slash `/` for hierarchical (directory)
grouping, but no slash-separated component can begin with a

View file

@ -29,7 +29,7 @@ arguments will in addition merge the remote master branch into the
current master branch, if any.
This default configuration is achieved by creating references to
the remote branch heads under `$GIT_DIR/refs/remotes/origin` and
the remote branch heads under `refs/remotes/origin` and
by initializing `remote.origin.url` and `remote.origin.fetch`
configuration variables.

View file

@ -18,7 +18,7 @@ higher level wrapper of this command, instead.
Invokes 'git-upload-pack' on a possibly remote repository
and asks it to send objects missing from this repository, to
update the named heads. The list of commits available locally
is found out by scanning local $GIT_DIR/refs/ and sent to
is found out by scanning the local refs/ hierarchy and sent to
'git-upload-pack' running on the other end.
This command degenerates to download everything to complete the

View file

@ -73,7 +73,7 @@ base-name::
--all::
This implies `--revs`. In addition to the list of
revision arguments read from the standard input, pretend
as if all refs under `$GIT_DIR/refs` are specified to be
as if all refs under `refs/` are specified to be
included.
--include-tag::

View file

@ -17,7 +17,7 @@ NOTE: In most cases, users should run 'git gc', which calls
'git prune'. See the section "NOTES", below.
This runs 'git fsck --unreachable' using all the refs
available in `$GIT_DIR/refs`, optionally with additional set of
available in `refs/`, optionally with additional set of
objects specified on the command line, and prunes all unpacked
objects unreachable from any of these head objects from the object database.
In addition, it

View file

@ -69,11 +69,11 @@ nor in any Push line of the corresponding remotes file---see below).
--all::
Instead of naming each ref to push, specifies that all
refs under `$GIT_DIR/refs/heads/` be pushed.
refs under `refs/heads/` be pushed.
--mirror::
Instead of naming each ref to push, specifies that all
refs under `$GIT_DIR/refs/` (which includes but is not
refs under `refs/` (which includes but is not
limited to `refs/heads/`, `refs/remotes/`, and `refs/tags/`)
be mirrored to the remote repository. Newly created local
refs will be pushed to the remote end, locally updated refs
@ -96,7 +96,7 @@ nor in any Push line of the corresponding remotes file---see below).
the same as prefixing all refs with a colon.
--tags::
All refs under `$GIT_DIR/refs/tags` are pushed, in
All refs under `refs/tags` are pushed, in
addition to refspecs explicitly listed on the command
line.

View file

@ -101,15 +101,14 @@ OPTIONS
abbreviation mode.
--all::
Show all refs found in `$GIT_DIR/refs`.
Show all refs found in `refs/`.
--branches[=pattern]::
--tags[=pattern]::
--remotes[=pattern]::
Show all branches, tags, or remote-tracking branches,
respectively (i.e., refs found in `$GIT_DIR/refs/heads`,
`$GIT_DIR/refs/tags`, or `$GIT_DIR/refs/remotes`,
respectively).
respectively (i.e., refs found in `refs/heads`,
`refs/tags`, or `refs/remotes`, respectively).
+
If a `pattern` is given, only refs matching the given shell glob are
shown. If the pattern does not contain a globbing character (`?`,
@ -189,7 +188,7 @@ blobs contained in a commit.
`g`, and an abbreviated object name.
* A symbolic ref name. E.g. 'master' typically means the commit
object referenced by $GIT_DIR/refs/heads/master. If you
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
@ -198,15 +197,15 @@ blobs contained in a commit.
. 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, `$GIT_DIR/refs/<name>` if exists;
. otherwise, `refs/<name>` if exists;
. otherwise, `$GIT_DIR/refs/tags/<name>` if exists;
. otherwise, `refs/tags/<name>` if exists;
. otherwise, `$GIT_DIR/refs/heads/<name>` if exists;
. otherwise, `refs/heads/<name>` if exists;
. otherwise, `$GIT_DIR/refs/remotes/<name>` if exists;
. otherwise, `refs/remotes/<name>` if exists;
. otherwise, `$GIT_DIR/refs/remotes/<name>/HEAD` 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
@ -217,6 +216,9 @@ 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

View file

@ -20,8 +20,8 @@ DESCRIPTION
-----------
Shows the commit ancestry graph starting from the commits named
with <rev>s or <globs>s (or all refs under $GIT_DIR/refs/heads
and/or $GIT_DIR/refs/tags) semi-visually.
with <rev>s or <globs>s (or all refs under refs/heads
and/or refs/tags) semi-visually.
It cannot show more than 29 branches and commits at a time.
@ -37,8 +37,8 @@ OPTIONS
<glob>::
A glob pattern that matches branch or tag names under
$GIT_DIR/refs. For example, if you have many topic
branches under $GIT_DIR/refs/heads/topic, giving
refs/. For example, if you have many topic
branches under refs/heads/topic, giving
`topic/*` would show all of them.
-r::
@ -176,7 +176,7 @@ EXAMPLE
-------
If you keep your primary branches immediately under
`$GIT_DIR/refs/heads`, and topic branches in subdirectories of
`refs/heads`, and topic branches in subdirectories of
it, having the following in the configuration file may help:
------------

View file

@ -33,7 +33,7 @@ A stash is by default listed as "WIP on 'branchname' ...", but
you can give a more descriptive message on the command line when
you create one.
The latest stash you created is stored in `$GIT_DIR/refs/stash`; older
The latest stash you created is stored in `refs/stash`; older
stashes are found in the reflog of this reference and can be named using
the usual reflog syntax (e.g. `stash@\{0}` is the most recently
created stash, `stash@\{1}` is the one before it, `stash@\{2.hours.ago}`

View file

@ -225,26 +225,26 @@ endif::git-rev-list[]
--all::
Pretend as if all the refs in `$GIT_DIR/refs/` are listed on the
Pretend as if all the refs in `refs/` are listed on the
command line as '<commit>'.
--branches[=pattern]::
Pretend as if all the refs in `$GIT_DIR/refs/heads` are listed
Pretend as if all the refs in `refs/heads` are listed
on the command line as '<commit>'. If `pattern` is given, limit
branches to ones matching given shell glob. If pattern lacks '?',
'*', or '[', '/*' at the end is implied.
--tags[=pattern]::
Pretend as if all the refs in `$GIT_DIR/refs/tags` are listed
Pretend as if all the refs in `refs/tags` are listed
on the command line as '<commit>'. If `pattern` is given, limit
tags to ones matching given shell glob. If pattern lacks '?', '*',
or '[', '/*' at the end is implied.
--remotes[=pattern]::
Pretend as if all the refs in `$GIT_DIR/refs/remotes` are listed
Pretend as if all the refs in `refs/remotes` are listed
on the command line as '<commit>'. If `pattern`is given, limit
remote tracking branches to ones matching given shell glob.
If pattern lacks '?', '*', or '[', '/*' at the end is implied.
@ -259,9 +259,9 @@ endif::git-rev-list[]
ifndef::git-rev-list[]
--bisect::
Pretend as if the bad bisection ref `$GIT_DIR/refs/bisect/bad`
Pretend as if the bad bisection ref `refs/bisect/bad`
was listed and as if it was followed by `--not` and the good
bisection refs `$GIT_DIR/refs/bisect/good-*` on the command
bisection refs `refs/bisect/good-*` on the command
line.
endif::git-rev-list[]
@ -561,10 +561,10 @@ Bisection Helpers
Limit output to the one commit object which is roughly halfway between
included and excluded commits. Note that the bad bisection ref
`$GIT_DIR/refs/bisect/bad` is added to the included commits (if it
exists) and the good bisection refs `$GIT_DIR/refs/bisect/good-*` are
`refs/bisect/bad` is added to the included commits (if it
exists) and the good bisection refs `refs/bisect/good-*` are
added to the excluded commits (if they exist). Thus, supposing there
are no refs in `$GIT_DIR/refs/bisect/`, if
are no refs in `refs/bisect/`, if
-----------------------------------------------------------------------
$ git rev-list --bisect foo ^bar ^baz
@ -585,7 +585,7 @@ one.
--bisect-vars::
This calculates the same as `--bisect`, except that refs in
`$GIT_DIR/refs/bisect/` are not used, and except that this outputs
`refs/bisect/` are not used, and except that this outputs
text ready to be eval'ed by the shell. These lines will assign the
name of the midpoint revision to the variable `bisect_rev`, and the
expected number of commits to be tested after `bisect_rev` is tested
@ -599,7 +599,7 @@ number of commits to be tested if `bisect_rev` turns out to be bad to
This outputs all the commit objects between the included and excluded
commits, ordered by their distance to the included and excluded
commits. Refs in `$GIT_DIR/refs/bisect/` are not used. The farthest
commits. Refs in `refs/bisect/` are not used. The farthest
from them is displayed first. (This is the only one displayed by
`--bisect`.)
+