git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Björn Steinbrink" <B.Steinbrink@gmx.de>
To: Nanako Shiraishi <nanako3@lavabit.com>
Cc: John Dlugosz <JDlugosz@TradeStation.com>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: fetch and pull
Date: Wed, 18 Mar 2009 09:58:49 +0100	[thread overview]
Message-ID: <20090318085849.GA8118@atjola.homenet> (raw)
In-Reply-To: <20090318063103.6117@nanako3.lavabit.com>

On 2009.03.18 06:31:03 +0900, Nanako Shiraishi wrote:
> Quoting John Dlugosz <JDlugosz@TradeStation.com>:
> > I think the documentation for git-pull might also be garbled from
> > text being of different eras.  "Normally the branch merged is the
> > HEAD of the remote"?  That will be basically random since the last
> > thing the upstream repo user did will control what his HEAD is.
> 
> That's how it's supposed to work, and the documentation isn't from a
> different era, either. Majority of users clone from a central
> repository and keep pulling to update their clones, and in that kind
> of setting, HEAD will never change. A HEAD in a bare repository tells
> people which branch is the primary branch of the project.

But _if_ HEAD changes in the remote repo, that has normally no effect on
the behaviour of pull. Especially since the examples in the man page are
"git pull" and "git pull origin".

AFAICT the remote's HEAD affects the pull behaviour when:

1) You do "git pull git://host/repo.git" or similar, i.e. you don't use
a remote. Because then, no refspec is given to fetch, and it defaults to
fetching HEAD.

2) You do "git pull origin" and there's no remote.origin.fetch set, same
as above then.

3) You do "git pull" and either is branch.<name>.remote set to an url
(same as 1) then) or to a remote that has no default fetch refspec set
(same as 2) then).


1) probably isn't that common for most users, and even if, it's not
one of the commands given as examples to which the paragraph applies.

2) I don't think that's a common setup, and it's not a default setup, so
that hardly qualifies for "normally".

3) I've actually seen cases of the first form of this setup (remote set
to an url), but usually that was paired with a confused user.


So while it's true that the remote's HEAD might be what you merge, it's
not quite what happens "normally". Of course it's true that the most
common setup is probably that HEAD references master and that
branch.<name>.merge is also set to refs/heads/master, but while the
outcome is basically the same, I'd rather say that that is a coincidence
rather than what the text means to the reader.


I'm unsure about how to improve that section though. Basically, the last
paragraph ("When no refspec was given ...") above the EXAMPLES section
needs to be repeated, but that feels wrong. Anyone got a better idea?

Well, at least I finally realised that pull _might_ default to the
remote's HEAD, and for that part, I'll send a patch.

Björn

  reply	other threads:[~2009-03-18  9:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AcmmaYOKDtJohyDSQt2B3xvVeIPNPw==>
2009-03-16 19:00 ` fetch and pull John Dlugosz
2009-03-16 20:03   ` Jay Soffian
2009-03-16 20:39     ` John Dlugosz
2009-03-16 20:43       ` Sverre Rabbelier
2009-03-17  8:34         ` Jeff King
2009-03-17  8:36           ` Sverre Rabbelier
2009-03-16 22:14       ` Jay Soffian
2009-03-16 22:33         ` John Dlugosz
2009-03-17  0:09           ` Jay Soffian
2009-03-17 14:58             ` John Dlugosz
2009-03-17 16:21               ` Jay Soffian
2009-03-17 16:44                 ` John Dlugosz
2009-03-17 21:31                   ` Nanako Shiraishi
2009-03-18  8:58                     ` Björn Steinbrink [this message]
2009-03-18  9:37                       ` Junio C Hamano
2009-03-18 15:18                       ` John Dlugosz
2009-03-18 15:31                         ` Björn Steinbrink
2009-03-18 16:50                           ` John Dlugosz
2009-03-18  0:37                   ` Jeff King
2009-03-06 19:04 John Dlugosz
2009-03-06 19:27 ` Junio C Hamano
2009-03-06 20:44 ` Jakub Narebski
2009-03-06 20:49   ` Junio C Hamano
2009-03-06 22:11     ` John Dlugosz
2009-03-06 22:21       ` Junio C Hamano
2009-03-07  8:00       ` Bryan Donlan
2009-03-07 20:15         ` Junio C Hamano
2009-03-09 15:27           ` John Dlugosz
2009-03-09 15:08         ` John Dlugosz

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=20090318085849.GA8118@atjola.homenet \
    --to=b.steinbrink@gmx.de \
    --cc=JDlugosz@TradeStation.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=nanako3@lavabit.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 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).