On Tue, 14 Nov 2006, Junio C Hamano wrote:
Nicolas Pitre [off-list ref] writes:
quoted
"You pull the remote changes with 'git-pull upstream,, then you can
merge them in your current branch with 'git-merge upstream'."
Isn't it much simpler to understand (and to teach) that way?
If it were "you download the remote changes with 'git download
upstream' and then merge with 'git merge'", then perhaps, but if
you used the word "pull" or "fetch", I do not think so.
I would be all for changing the semantics of "pull" from one
thing to another, if the new semantics were (1) what everybody
welcomed, (2) what "pull" traditionally meant everywhere else.
In that case, we have been misusing it to be confusing to
outsiders and I agree it makes a lot of sense to remove the
source of confusion. But I do not think CVS nor SVN ever used
the term, and I was told that BK was what introduced the term,
and the word meant something different from what you are
proposing.
You have to admit both pull and fetch have been contaminated
with loaded meanings from different backgrounds. I was talking
about killing the source of confusion in the longer term by
removing fetch/pull/push, so we are still on the same page.
That's where my "you download from the upstream and merge" comes
from.
But the fact is that HG (which has a growing crowd of happy campers,
maybe even larger than the BK crowd now) did work with and got used to a
sensible definition of what a "pull" is. This means that their
definition is becoming rather more relevant with time than what it used
to, and because it is a saner definition than what GIT has for the same
word which HG users really have no issue with, I think we really should
leverage the "common wisdom" and consider aligning ourselves with them
in this case rather than trying to go into a totally different
direction. We simply won't gain anything trying to teach people "a pull
in HG is a download in GIT". If a pull becomes the same thing for both
then it's one less oddball in the GIT interface.