Re: Cleaning up git user-interface warts

On Wed, 15 Nov 2006 12:40:43 -0800 (PST), Linus Torvalds wrote:

On Wed, 15 Nov 2006, Nicolas Pitre wrote:

quoted

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