From: Jonathan Nieder <jrnieder@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Thomas Rast" <trast@student.ethz.ch>,
git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Geoff Russell" <geoffrey.russell@gmail.com>
Subject: [PATCH] Documentation: flesh out “git pull” description
Date: Mon, 2 Aug 2010 16:39:30 -0500 [thread overview]
Message-ID: <20100802213930.GA3506@burratino> (raw)
In-Reply-To: <7v7hk9p2f4.fsf@alter.siamese.dyndns.org>
The current description in the pull man page does not say much more
than that “git pull” is fetch + merge. Though that is all a person
needs to know in the end, it would be useful to summarize a bit about
what those commands do for new readers.
Most of this description is taken from the “git merge” docs.
Now that we explain how to back out of a failed merge (reset --merge),
we can tone down the warning against that a bit.
Except, as Thomas noticed, there’s a risk with that because people
might read this version of the manpage online and then conclude that
it is safe to try a merge with uncommitted changes, only to find that
their “git reset” doesn't support --merge yet. Or worse, verify that
their git-reset has --merge by a quick test (1b5b465 is in 1.6.2) but
then find that it does not help with backing out of a merge (e11d7b5
is only in 1.7.0!). So keep the warning.
With clarifications from Ævar, Thomas, and Junio.
Noticed-by: Geoff Russell <geoffrey.russell@gmail.com>
Cc: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Cc: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:
> I think the longer "In git 1.7.0 or later" with "Warning: in olden days"
> can appear in everybody's version without causing any harm. That way, it
> is shown even to somebody who came to docs/v1.7.3/git-pull.html at k.org
> from sideways.
Ok. Here’s what it looks like with that change.
Documentation/git-pull.txt | 65 ++++++++++++++++++++++++++++++++++++-------
1 files changed, 54 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index ab4de10..7e72961 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -8,29 +8,72 @@ git-pull - Fetch from and merge with another repository or a local branch
SYNOPSIS
--------
-'git pull' <options> <repository> <refspec>...
+'git pull' [options] [<repository> [<refspec>...]]
DESCRIPTION
-----------
-Runs 'git fetch' with the given parameters, and calls 'git merge'
-to merge the retrieved head(s) into the current branch.
-With `--rebase`, calls 'git rebase' instead of 'git merge'.
-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.
+Incorporates changes from a remote repository into the current
+branch. In its default mode, `git pull` is shorthand for
+`git fetch` followed by `git merge FETCH_HEAD`.
-Also note that options meant for 'git pull' itself and underlying
-'git merge' must be given before the options meant for 'git fetch'.
+More precisely, 'git pull' runs 'git fetch' with the given
+parameters and calls 'git merge' to merge the retrieved branch
+heads into the current branch.
+With `--rebase`, it runs 'git rebase' instead of 'git merge'.
-*Warning*: Running 'git pull' (actually, the underlying 'git merge')
+<repository> should be the name of a remote repository as
+passed to linkgit:git-fetch[1]. <refspec> can name an
+arbitrary remote ref (for example, the name of a tag) or even
+a collection of refs with corresponding remote tracking branches
+(e.g., refs/heads/*:refs/remotes/origin/*), but usually it is
+the name of a branch in the remote repository.
+
+Default values for <repository> and <branch> are read from the
+"remote" and "merge" configuration for the current branch
+as set by linkgit:git-branch[1] `--track`.
+
+Assume the following history exists and the current branch is
+"`master`":
+
+------------
+ A---B---C master on origin
+ /
+ D---E---F---G master
+------------
+
+Then "`git pull`" will fetch and replay the changes from the remote
+`master` branch since it diverged from the local `master` (i.e., `E`)
+until its current commit (`C`) on top of `master` and record the
+result in a new commit along with the names of the two parent commits
+and a log message from the user describing the changes.
+
+------------
+ A---B---C remotes/origin/master
+ / \
+ D---E---F---G---H master
+------------
+
+See linkgit:git-merge[1] for details, including how conflicts
+are presented and handled.
+
+In git 1.7.0 or later, to cancel a conflicting merge, use
+`git reset --merge`. *Warning*: In older versions of git, running 'git pull'
with uncommitted changes is discouraged: while possible, it leaves you
-in a state that is hard to back out of in the case of a conflict.
+in a state that may be hard to back out of in the case of a conflict.
+
+If any of the remote changes overlap with local uncommitted changes,
+the merge will be automatically cancelled and the work tree untouched.
+It is generally best to get any local changes in working order before
+pulling or stash them away with linkgit:git-stash[1].
OPTIONS
-------
+Options meant for 'git pull' itself and the underlying 'git merge'
+must be given before the options meant for 'git fetch'.
+
-q::
--quiet::
This is passed to both underlying git-fetch to squelch reporting of
--
1.7.2.1.544.ga752d.dirty
prev parent reply other threads:[~2010-08-02 21:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-01 2:54 [PATCH/RFC v2] Documentation: flesh out “git pull” description Jonathan Nieder
2010-08-01 3:03 ` [PATCH/RFC v2 resend] " Jonathan Nieder
2010-08-02 4:32 ` [PATCH/RFC v2] " Junio C Hamano
2010-08-02 12:34 ` Thomas Rast
2010-08-02 13:30 ` Junio C Hamano
2010-08-02 21:39 ` Jonathan Nieder [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100802213930.GA3506@burratino \
--to=jrnieder@gmail.com \
--cc=avarab@gmail.com \
--cc=geoffrey.russell@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=trast@student.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).