On Wed, 15 Nov 2006 12:40:43 -0800 (PST), Linus Torvalds wrote: > 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. Well, one of the problems is that with current git I can teach, (and I have), that there's a conceptual: pull = fetch + merge But then shortly after I have to teach an interface notion: merge = pull . So there's this goofy circular notion that people end up with mentally. If we fix it so that a local merge really is performed with "git merge <branch>" instead of "git pull . <branch>" then teaching pull=fetch+merge really is a lot easier. In the meantime, pull would still be useless to me, I think. But maybe that's just the "default branch to merge" selection being broken. If that were fixed, maybe I would start using pull. > (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). There's a piece missing here, namely the mapping between remote and local branch names and any notion of "tracking branches". I think a sane story for that is still being invented, (or if it exists now, I haven't seen it yet). > (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. Well, they get pretty darn confused at this point, in my experience. > 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. No. It's really, really broken to use "pull ." for local merging. Not a feature at all. We just got done establishing that pull is a shorthand for doing fetch+merge, so reusing it when there is _no_ fetch at all is insane. You just established quite clearly hat git has a huge advantge over all other systems by having a model that everything is fetched in and then worked with locally. I agree that this is a major selling-point of git, and I'm also baffled that systems like bzr and hg try so hard to push every branch into a separate repository. But I think that git's "work with everything locally" story is undercut a bit by regular usage being to use a transfer-inducing command like "pull" for a totally local merge. Anyway, I think we all agree that we'd really rather have "git merge <branch>" be usable for local merges, so let's get that in place and users can pick whichever they like. > 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. Totally agree. -Carl
Attachment:
pgpFekKexv1YH.pgp
Description: PGP signature