All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Alexander Litvinov <litvinov2004@gmail.com>
Cc: git@vger.kernel.org, Bill Lear <rael@zopyra.com>
Subject: Re: Git rescue mission
Date: Thu, 08 Feb 2007 16:53:32 -0800	[thread overview]
Message-ID: <7vy7n8up6b.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <200702081028.31493.litvinov2004@gmail.com> (Alexander Litvinov's message of "Thu, 8 Feb 2007 10:28:31 +0600")

Alexander Litvinov <litvinov2004@gmail.com> writes:

> I think this should go to git-pull/git-clone man
> pages. Personaly for me this post dispels dark magic about
> git-pull's merging logic. I always did git-fetch and then
> git-pull . <some-branch> to control what and where should be
> merged.

Fair enough.  But I am known to be very bad at writing, so I
would ask the list to proofread this to see if it makes sense,
and prefereably rewrite it to make it easier to understand.

I think it is technically accurate -- I just do not know if I am
not writing enough, leaving certain necessary things unsaid,
because I assumed (wrongly) too much knowledge on the reader's
side.


diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index a81d68c..94478ed 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -33,6 +33,60 @@ include::urls.txt[]
 
 include::merge-strategies.txt[]
 
+DEFAULT BEHAVIOUR
+-----------------
+
+Often people use `git pull` without giving any parameter.
+Traditionally, this has been equivalent to saying `git pull
+origin`.  However, when configuration `branch.<name>.remote` is
+present while on branch `<name>`, that value is used instead of
+`origin`.
+
+In order to determine what URL to use to fetch from, the value
+of the configuration `remote.<origin>.url` is consulted
+and if there is not any such variable, the value on `URL: ` line
+in `$GIT_DIR/remotes/<origin>` file is used.
+
+In order to determine what remote branches to fetch (and
+optionally store in the tracking branches) when the command is
+run without any refspec parameters on the command line, values
+of the configuration variable `remote.<origin>.fetch` are
+consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>`
+file is consulted and its `Pull: ` lines are used.
+In addition to the refspec formats described in the OPTIONS
+section, you can have a globbing refspec that looks like this:
+
+------------
+refs/heads/*:refs/remotes/origin/*
+------------
+
+A globbing refspec must have a non-empty RHS (i.e. must store
+what were fetched in tracking branches), and its LHS and RHS
+must end with `/*`.  The above specifies that all remote
+branches are tracked using tracking branches in
+`refs/remotes/origin/` hierarchy under the same name.
+
+The rule to determine which remote branch to merge after
+fetching is a bit involved, in order not to break backward
+compatibility.
+
+If explicit refspecs were given on the command
+line of `git pull`, they are all merged.
+
+When no refspec was given on the command line, then `git pull`
+uses the refspec from the configuration or
+`$GIT_DIR/remotes/<origin>`.  In such cases, the following
+rules apply:
+
+. If `branch.<name>.merge` configuration for the current
+  branch `<name>` exists, that is the name of the branch at the
+  remote site that is merged.
+
+. If the refspec is a globbing one, nothing is merged.
+
+. Otherwise the remote branch of the first refspec is merged.
+
+
 EXAMPLES
 --------
 

  reply	other threads:[~2007-02-09  0:53 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-08  0:18 Git rescue mission Bill Lear
2007-02-08  0:22 ` Johannes Schindelin
2007-02-08  0:24   ` Bill Lear
2007-02-08  0:25     ` Johannes Schindelin
2007-02-08  0:34       ` Bill Lear
2007-02-08  0:48 ` Junio C Hamano
2007-02-08  4:28   ` Alexander Litvinov
2007-02-09  0:53     ` Junio C Hamano [this message]
2007-02-09  3:32       ` Alexander Litvinov
2007-02-08 15:27   ` Bill Lear
2007-02-08 15:56     ` Jakub Narebski
2007-02-08 23:24     ` Jeff King
2007-02-08 23:32       ` Bill Lear
2007-02-08 17:27 ` Linus Torvalds
2007-02-08 20:12   ` Kalle Pokki
2007-02-08 21:23     ` Linus Torvalds
2007-02-08 22:03       ` Kalle Pokki
2007-02-08 22:10         ` Shawn O. Pearce
2007-02-09  1:48           ` Theodore Tso
2007-02-09  1:58             ` Shawn O. Pearce
2007-02-09  2:01             ` Jakub Narebski
2007-02-10 16:05             ` Theodore Ts'o
2007-02-10 16:05               ` [PATCH] Print a sane error message if an alias expands to an invalid git command Theodore Ts'o
2007-02-10 16:05                 ` [PATCH] Allow aliases to expand to shell commands Theodore Ts'o
2007-02-10 18:04                   ` Linus Torvalds
2007-02-10 18:13                   ` Theodore Tso
2007-02-10 20:34                     ` Johannes Schindelin
2007-02-11  0:13                       ` Theodore Tso
2007-02-11 16:03                         ` Johannes Schindelin
2007-02-11 16:21                           ` Theodore Tso
2007-02-11 16:36                             ` Johannes Schindelin
2007-02-11 21:44                             ` Junio C Hamano
2007-02-11 22:03                               ` Johannes Schindelin
2007-02-12  3:56                               ` Theodore Tso
2007-02-12  6:53                                 ` Shawn O. Pearce
2007-02-10 16:50                 ` [PATCH] Print a sane error message if an alias expands to an invalid git command Junio C Hamano
2007-02-09 19:21           ` Git rescue mission Kalle Pokki
2007-02-08 21:57   ` Bill Lear
2007-02-08 22:13     ` Linus Torvalds
2007-02-08 22:33       ` Bill Lear
2007-02-08 23:25       ` Bill Lear
2007-02-08 23:33         ` Shawn O. Pearce
2007-02-08 23:40           ` Bill Lear
2007-02-08 23:50             ` Shawn O. Pearce
2007-02-09  0:03             ` Jakub Narebski
2007-02-09  0:17             ` Linus Torvalds
2007-02-09  8:58             ` Michael S. Tsirkin
2007-02-08 23:38         ` Jakub Narebski
2007-02-08 23:46         ` Linus Torvalds
2007-02-09  4:38       ` Junio C Hamano
2007-02-08 22:29     ` Jakub Narebski

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=7vy7n8up6b.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=litvinov2004@gmail.com \
    --cc=rael@zopyra.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.