On Wed, 15 Nov 2006, Nicolas Pitre wrote:
>
> Actually I believe it would make things even clearer if "merge" was
> taught at that point. Only when the user is comfortable with the
> separate notions of fetching and merging might the pull shorthand
> possibly be mentioned.
I agree. I just expect that "merge" is such a simple concept that it
doesn't really need a whole lot of explaining.
People kind of expect merging to be hard, but I think it's because CVS et
al have tought people that merging is _painful_. I don't think it's a very
complicated concept per se, especially if you have explained branches with
gitk already.
But yes, the order should be:
(a) explain what "branches" mean in git (and in that situation, "fetch"
is very natural - I think fetching itself is probably easier to
explain than "branches" are).
(b) once you've explained branches, the notion of "merge" comes next, and
I _think_ that is very obvious. This is where UI issues come in,
because "git merge" is really a totally internal program with a
pretty horrid UI, but I think we could fix the syntax, and even with
the current syntax you can really just gloss it over, because nobody
is really going to care.
(c) once "fetching branches" and "merging" have been explained, "pull" is
really pretty damn trivial, and in fact, if you then explain that
it's just easier to do "git pull . branchname" than to use "git
merge", I think people may just even agree with you.
I think I saw that particular discussion on #git: somebody didn't expect
"git pull . branch" to be the way to merge. And again, I think it's
not _really_ because "pull" is hard to understand, it's because people
haven't been walked through the thing in this way.
Once you understand local branches, fetching and merging, it's actually
_easier_ to explain why we merge even local branches with "git pull .":
you just tell them that this way you can use the same command regardless
of whether you're merging something local or something remote. Again, if
it's explained that way, I bet a lot of people react with "ahh, that's
clever", and _like_ the fact that they only really need to learn _one_
command, instead of learning two.
See? Explain it that way: "pull" really is simple. By using "pull", you
don't have to learn about "merge" syntax. You -can- use "merge" as a
separate program if you want to, but the syntax isn't very nice, exactly
because you're not really expected to.
But the real issue here is to explain local branches. I will happily admit
that local branches are very VERY different from just about any other SCM,
but I also claim that git is just much BETTER than other SCM's in this
respect.
And yes, this is why you should NOT try to use the same naming as "hg",
for example. Last I saw, hg still didn't even have local branches, To
mercurial, repository == branch, and that's it. It was what I came from
too, and I used to argue for using git that way too. I've since seen the
error of my ways, and git is simply BETTER.
And the concept of local branches is exactly _why_ you have to have
separate "fetch" and "pull", but why you do _not_ need a separate "merge"
(because "pull ." does it for you).
If you don't understand local branches, you'll never understand git usage.
And once you _do_ understand local branches, "fetch" vs "pull" actually is
rather simple.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html