From: Linus Torvalds <torvalds@osdl.org>
To: Petr Baudis <pasky@suse.cz>
Cc: Shawn Pearce <spearce@spearce.org>, git@vger.kernel.org
Subject: Re: Git user survey and `git pull`
Date: Thu, 21 Sep 2006 10:38:04 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0609211027440.4388@g5.osdl.org> (raw)
In-Reply-To: <20060921164048.GY8259@pasky.or.cz>
On Thu, 21 Sep 2006, Petr Baudis wrote:
>
> This is artifact of the BitKeeper terminology. This is the meaning in
> most other VCSes but in BitKeeper, pull meant "get changes and merge
> them", not just "get changes". So the BitKeeper legacy lives on. :-)
Indeed. "pull/push" are the operations bk has.
BK doesn't have branches, and cannot do a "fetch", so there's no confusion
in BK - the pulls and the pushes are not mirror-images, but since there
are no other operations you'd normally use, you can pretty much ignore it.
(That's not entirely true. In BK, you can do "bk receive" and "bk resolve"
to "fetch" and "merge" another branch, but quite frankly, I personally
found them so confusing that I never used them at all).
I agree that the clarifications from Shawn are probably improvements, but
I'd actually like to solve the problem a bit differently. Namely, I was
hoping that the per-branch configuration would solve the confusion.
Right now, a plain "git pull" means "fetch all branches and merge the
first one", and the thing is, that's generally the right thing _only_ if
you pull into "master".
It's usually exactly the _wrong_ thing to do for any other branch. In
particular, if you work with a project that has lots of branches, and
you're working in another branch (that is directly tracking a remote, for
example), doing a "git pull" definitely should _not_ merge the first head.
It should fetch everything, and possibly merge the _matching_ head.
Which it doesn't do right now.
So I think the problem with "git pull" is not that it's a "fetch and
merge", it's that it merges the wrong head. It always merges the first
remote one (aka the remote "HEAD"), regardless of which head we happen to
be at right now.
So I was kind of hoping that the per-branch configuration stuff (that
petered out after the .git/config file format was worked out) would solve
the problem.
That said, maybe Shawn's suggestion is better. And maybe the fact that
we'd change the semantics mid-stream would make things even WORSE. I
dunno.
Linus
next prev parent reply other threads:[~2006-09-21 17:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-21 16:24 Git user survey and `git pull` Shawn Pearce
2006-09-21 16:40 ` Petr Baudis
2006-09-21 17:38 ` Linus Torvalds [this message]
2006-09-21 18:05 ` Nicolas Pitre
2006-09-22 4:57 ` Junio C Hamano
2006-09-22 10:34 ` Santi
2006-09-22 19:08 ` Junio C Hamano
2006-09-22 23:24 ` Santi
2006-09-21 17:02 ` Nicolas Pitre
2006-09-21 17:09 ` Shawn Pearce
2006-09-21 17:12 ` Johannes Schindelin
2006-09-21 17:17 ` Jakub Narebski
2006-09-22 21:05 ` Matthias Urlichs
2006-09-23 11:51 ` Alan Chandler
2006-09-23 14:12 ` Johannes Schindelin
2006-09-23 8:54 ` 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=Pine.LNX.4.64.0609211027440.4388@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=pasky@suse.cz \
--cc=spearce@spearce.org \
/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).