On Wed, 15 Nov 2006, Nicolas Pitre wrote:
quoted text
> 
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html