I'm saying that people who are new to git will _have_ to learn new
concepts ANYWAY.
I don't think the naming is the hard part.
The fact is, git is one of the very few (essentially _only_) SCM's that
make it very clear that all real operations are local and that if you want
to work with other repositories, you have to "fetch" those into local
branches first. The fact that "pull" exists at all is really just
shorthand.
If people have trouble explaining this to others, and have trouble
grasping "pull", then I will bet that the _real_ issue has nothing at all
to do with naming at all, and the real issue is that people are being
_taught_ the concepts in the wrong order.
Before you learn "pull", you should learn "fetch". Don't even _mention_
"pull" until the person got what "fetch" means. Because the fact is,
"fetch" is really the much more fundamental operation, and once you
really understand what "fetch" does, "pull" is obvious.
So I'll argue that the problem isn't naming, the "problem" is really that
git has a few fundamnetal concepts that people aren't used to. The most
fundamnetal of those is the notion of the local branch-space. EVERY other
(broken) SCM has branches as being some kind of totally idiotic separate
subdirectories, or doesn't really support branches at all (ie neither BK
nor CVS really support "branches" - even if a concept of that name exists
in CVS, it has nothing at all in common with the git model of branches).
But once you understand branches, and understand "fetch" (and it really
isn't _that_ complicated: fetch really does exactly what the name says, so
if you understand local branches, you will understand "fetch"), then it's
a much smaller step to explain "pull = fetch + merge".
But I bet people don't teach it that way. They _start_ by teaching "pull".
Right?
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
