Added a few examples to git-pull man page.

Clarified and added notes for pull/push refspecs.
Converted to back-ticks for literal text examples.

[jc: Also fixed git-pull description that still talked about its
calling git-resolve or git-octopus (we do not anymore; instead
we just call git-merge).  BTW, I am reasonably impressed by how
well "git-am -3" applied this patch, which had some conflicts
because I've updated the documentation somewhat.]

Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This commit is contained in:
Jon Loeliger 2005-11-04 20:36:08 -06:00 committed by Junio C Hamano
parent d8ae1d10cd
commit bccf5956c3
2 changed files with 103 additions and 32 deletions

View file

@ -13,13 +13,10 @@ SYNOPSIS
DESCRIPTION
-----------
Runs 'git-fetch' with the given parameters.
Runs `git-fetch` with the given parameters, and calls `git-merge`
to merge the retrieved head(s) into the current branch.
When only one ref is downloaded, runs 'git resolve' to merge it
into the local HEAD. Otherwise uses 'git octopus' to merge them
into the local HEAD.
Note that you can use '.' (current directory) as the
Note that you can use `.` (current directory) as the
<repository> to pull from the local repository -- this is useful
when merging local branches into the current branch.
@ -29,8 +26,8 @@ include::pull-fetch-param.txt[]
-a, \--append::
Append ref names and object names of fetched refs to the
existing contents of $GIT_DIR/FETCH_HEAD. Without this
option old data in $GIT_DIR/FETCH_HEAD will be overwritten.
existing contents of `$GIT_DIR/FETCH_HEAD`. Without this
option old data in `$GIT_DIR/FETCH_HEAD` will be overwritten.
include::merge-pull-opts.txt[]
@ -97,6 +94,52 @@ You should refrain from abusing this option to sneak substantial
changes into a merge commit. Small fixups like bumping
release/version name would be acceptable.
Command line pull of multiple branches from one repository::
+
------------------------------------------------
$ cat .git/remotes/origin
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: master:origin
$ git checkout master
$ git fetch origin master:origin +pu:pu maint:maint
$ git pull . origin
------------------------------------------------
+
Here, a typical `$GIT_DIR/remotes/origin` file from a
`git-clone` operation is used in combination with
command line options to `git-fetch` to first update
multiple branches of the local repository and then
to merge the remote `origin` branch into the local
`master` branch. The local `pu` branch is updated
even if it does not result in a fast forward update.
Here, the pull can obtain its objects from the local
repository using `.`, as the previous `git-fetch` is
known to have already obtained and made available
all the necessary objects.
Pull of multiple branches from one repository using `$GIT_DIR/remotes` file::
+
------------------------------------------------
$ cat .git/remotes/origin
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: master:origin
Pull: +pu:pu
Pull: maint:maint
$ git checkout master
$ git pull origin
------------------------------------------------
+
Here, a typical `$GIT_DIR/remotes/origin` file from a
`git-clone` operation has been hand-modified to include
the branch-mapping of additional remote and local
heads directly. A single `git-pull` operation while
in the `master` branch will fetch multiple heads and
merge the remote `origin` head into the current,
local `master` branch.
Author
------
@ -105,7 +148,9 @@ and Junio C Hamano <junkio@cox.net>
Documentation
--------------
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
Documentation by Jon Loeliger,
David Greaves,
Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---

View file

@ -1,7 +1,8 @@
<repository>::
The "remote" repository to pull from. One of the
following notations can be used to name the repository
to pull from:
The "remote" repository that is the source of a fetch
or pull operation, or the destination of a push operation.
One of the following notations can be used
to name the remote repository:
+
===============================================================
- Rsync URL: rsync://remote.machine/path/to/repo.git/
@ -12,7 +13,7 @@
===============================================================
+
In addition to the above, as a short-hand, the name of a
file in $GIT_DIR/remotes directory can be given; the
file in `$GIT_DIR/remotes` directory can be given; the
named file should be in the following format:
+
URL: one of the above URL format
@ -21,57 +22,82 @@ named file should be in the following format:
+
When such a short-hand is specified in place of
<repository> without <refspec> parameters on the command
line, <refspec>... specified on Push lines or Pull lines
are used for "git push" and "git fetch/pull",
respectively.
line, <refspec>... specified on `Push:` lines or `Pull:`
lines are used for `git-push` and `git-fetch`/`git-pull`,
respectively. Multiple `Push:` and and `Pull:` lines may
be specified for additional branch mappings.
+
The name of a file in $GIT_DIR/branches directory can be
The name of a file in `$GIT_DIR/branches` directory can be
specified as an older notation short-hand; the named
file should contain a single line, a URL in one of the
above formats, optionally followed by a hash '#' and the
above formats, optionally followed by a hash `#` and the
name of remote head (URL fragment notation).
$GIT_DIR/branches/<remote> file that stores a <url>
`$GIT_DIR/branches/<remote>` file that stores a <url>
without the fragment is equivalent to have this in the
corresponding file in the $GIT_DIR/remotes/ directory
corresponding file in the `$GIT_DIR/remotes/` directory.
+
URL: <url>
Pull: refs/heads/master:<remote>
+
while having <url>#<head> is equivalent to
while having `<url>#<head>` is equivalent to
+
URL: <url>
Pull: refs/heads/<head>:<remote>
<refspec>::
The canonical format of a <refspec> parameter is
'+?<src>:<dst>'; that is, an optional plus '+', followed
by the source ref, followed by a colon ':', followed by
`+?<src>:<dst>`; that is, an optional plus `+`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
When used in "git push", the <src> side can be an
When used in `git-push`, the <src> side can be an
arbitrary "SHA1 expression" that can be used as an
argument to "git-cat-file -t". E.g. "master~4" (push
argument to `git-cat-file -t`. E.g. `master~4` (push
four parents before the current master head).
+
For "git push", the local ref that matches <src> is used
For `git-push`, the local ref that matches <src> is used
to fast forward the remote ref that matches <dst>. If
the optional plus '+' is used, the remote ref is updated
the optional plus `+` is used, the remote ref is updated
even if it does not result in a fast forward update.
+
For "git fetch/pull", the remote ref that matches <src>
For `git-fetch` and `git-pull`, the remote ref that matches <src>
is fetched, and if <dst> is not empty string, the local
ref that matches it is fast forwarded using <src>.
Again, if the optional plus '+' is used, the local ref
Again, if the optional plus `+` is used, the local ref
is updated even if it does not result in a fast forward
update.
+
[NOTE]
If the remote branch from which you want to pull is
modified in non-linear ways such as being rewound and
rebased frequently, then a pull will attempt a merge with
an older version of itself, likely conflict, and fail.
It is under these conditions that you would want to use
the `+` sign to indicate non-fast-forward updates will
be needed. There is currently no easy way to determine
or declare that a branch will be made available in a
repository with this behavior; the pulling user simply
must know this is the expected usage pattern for a branch.
+
[NOTE]
You never do your own development on branches that appear
on the right hand side of a <refspec> colon on `Pull:` lines;
they are to be updated by `git-fetch`. The corollary is that
a local branch should be introduced and named on a <refspec>
right-hand-side if you intend to do development derived from
that branch.
This leads to the common `Pull: master:origin` mapping of a
remote `master` branch to a local `origin` branch, which
is then merged to a local development branch, again typically
named `master`.
+
Some short-cut notations are also supported.
+
* For backward compatibility, "tag" is almost ignored;
* For backward compatibility, `tag` is almost ignored;
it just makes the following parameter <tag> to mean a
refspec "refs/tags/<tag>:refs/tags/<tag>".
refspec `refs/tags/<tag>:refs/tags/<tag>`.
* A parameter <ref> without a colon is equivalent to
<ref>: when pulling/fetching, and <ref>:<ref> when
<ref>: when pulling/fetching, and <ref>`:`<ref> when
pushing. That is, do not store it locally if
fetching, and update the same name if pushing.