I'm saying that even if you _never_ end up using "git fetch" ever again
(because in practice you always want to do a "fetch + merge == pull"),
people who teach others the concepts and usage of git should probably
start by talking about "git fetch".
Then, when the user says (and he obviously will say this) "but I don't
want to just fetch the other persons work into some local branch, I want
to actually get it into _my_ branch", you say "Ahhah!" and talk about how
"pull" is a shorthand for first fetching and then merging the result into
the current branch.
See? Once you explain "fetch" to somebody, I can pretty much guarantee
that they'll explain "pull" to themselves without you having to even work
at it. And then they'll probably happily use "pull" ever after, and never
worry about fetch, but now they'll understand the _concepts_.
It's only if you start the other way around that "pull" vs "fetch" vs
"push" become confusing. If you _start_ by explaining branches (and you
might use "gitk --all" on a small project as a visualization tool),
suddenly the concepts aren't all that complicated.
Sure, then you have to remember two words ("pull" vs "fetch"), but I'm
pretty sure that the thing that makes people confused is not the words
themselves, but their lack of understanding of the concepts behind them.
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
