Re: [RFC] pull/fetch rename

"Wesley J. Landaker" [off-list ref] writes:

On Tuesday 20 October 2009 11:47:45 Thomas Rast wrote:

quoted

Especially on IRC, we see many people who are some combination of
misunderstanding, misusing or overusing git-pull.  I figure this is
the result of several factors, notably

a) pull/push are not symmetric,

b) guides/tutorials recommend pull for situations where they
   shouldn't,

c) people blindly fire commands at git.

This may be minor, but also:

d) in mercurial, pull/push are symmetric, but fetch means pull+merge

quoted

As you probably guessed by now, here is an idea for a very aggressive
transition plan to address (a) in four phases:

I would love to see this change, not because I get confused about pull/fetch 
(it honestly only took a few days to get used to), but because having 
push/pull be symmetric just is so much more conceptually pure / easier 
explain to co-workers / separation between orthogonal operations / 
satisfying to my inner perfectionist / etc.

Is making "pull" a symmetric opposite of "push" the ultimate goal?

Or is making (or rather "keeping") "pull" useful more important?

It is not even an attitude that values philosophy over utility.

Fundamentally, pull and push cannot be symmetric because nobody is sitting
in front of the repository you are pushing into (that is what a "push" is;
you push from outside the repository---otherwise you would be "pull"ing
from inside it in the other direction), but you know you are sitting in
the repository, ready to resolve potential conflicts, when you say "pull".

Your elaborate scheme to make "pull" into "fetch" and to force everybody
to set a configuration variable to make it "pull" again sounds like a
mindless mental masturbation to me.  People who leave "pull.merge = no"
will always have to say "pull --merge" or "pull --rebase", so you cannot
even argue you are not forcing but giving them a choice.

And you are doing this for what gain?  The only thing I can think of is
"People who deliberately set 'pull.merge = yes' can no longer blame us for
pull not being the opposite of push."  I do not consider it as a gain.

I do not buy "People who set 'pull.merge = yes' now understand why pull
touches their work tree, because they did it themselves" either.  People
blindly copy other people's configuration from random web pages without
understanding.  Besides, the next thing they will ask is "Why is there
pull.merge but no push.merge?  Wasn't push an opposite of pull?" and you
are back to square one.

I would be much more sympathetic if the suggested approach were to make
"push" more symmetric to "pull", or at least attempt to allow it to be, by
giving it an option to update the associated work tree when it can [*1*].

But I do not know what to say when people say "push cannot update the work
tree, so let's make pull not to update the work tree by default---it will
make it much less useful so we will fix that regression with yet another
configuration option".  It's not even funny.


[Footnote]

*1* Obviously you cannot do this most of the time _if_ the work tree has
an interactive user sitting in front of it, but in a repository that never
allows a non-ff push, with a work tree that is never updated except by
such a push, can reasonably be maintained to give an illusion of push
being an opposite of pull by fast forwarding the work tree when the push
updates HEAD.

Junio C Hamano wrote:

"Wesley J. Landaker" [off-list ref] writes:

quoted

d) in mercurial, pull/push are symmetric, but fetch means pull+merge

Ugh.  I can see how they arrived at hg-pull == git-fetch, but why on
earth was the logical next step hg-fetch == git-pull?!

</aside>

quoted

I would love to see this change, not because I get confused about pull/fetch 
(it honestly only took a few days to get used to), but because having 
push/pull be symmetric just is so much more conceptually pure / easier 
explain to co-workers / separation between orthogonal operations / 
satisfying to my inner perfectionist / etc.

Is making "pull" a symmetric opposite of "push" the ultimate goal?

Or is making (or rather "keeping") "pull" useful more important?

It is not even an attitude that values philosophy over utility.

Fundamentally, pull and push cannot be symmetric because nobody is sitting
in front of the repository you are pushing into (that is what a "push" is;
you push from outside the repository---otherwise you would be "pull"ing
from inside it in the other direction), but you know you are sitting in
the repository, ready to resolve potential conflicts, when you say "pull".

Well, I'd rather not argue the little semantic details, but I think
with the changes to disallow pushing into HEAD, push and fetch are as
symmetric as it gets.  Both are exactly and only about transmitting
refs with their associated commits to the other side.  Which one you
pick only depends on which side you sit on.

OTOH pull is about merging.  And we can repeat the "pull = fetch +
merge" mantra to ourselves all we like, having pull as "the opposite
of push" is conceptually much easier to understand and thus far easier
to explain to new users.

And you are doing this for what gain?  The only thing I can think of is
"People who deliberately set 'pull.merge = yes' can no longer blame us for
pull not being the opposite of push."  I do not consider it as a gain.

I do not buy "People who set 'pull.merge = yes' now understand why pull
touches their work tree, because they did it themselves" either.

[...]

But I do not know what to say when people say "push cannot update the work
tree, so let's make pull not to update the work tree by default---it will
make it much less useful so we will fix that regression with yet another
configuration option".

There would not be a configuration option.

Really, the whole goal would be to make pull the opposite of push.  No
exceptions, and most certainly no little loopholes to escape into the
merging behaviour by default.  The current 'git pull' behaviour would
either be obtained through a new command, or through an explicit
switch.

I would be much more sympathetic if the suggested approach were to make
"push" more symmetric to "pull", or at least attempt to allow it to be, by
giving it an option to update the associated work tree when it can [*1*].

[...]

*1* Obviously you cannot do this most of the time _if_ the work tree has
an interactive user sitting in front of it, but in a repository that never
allows a non-ff push, with a work tree that is never updated except by
such a push, can reasonably be maintained to give an illusion of push
being an opposite of pull by fast forwarding the work tree when the push
updates HEAD.

Well, that reminds me of

  http://thread.gmane.org/gmane.comp.version-control.git/110251

but was not really what I was aiming at.

It's not even funny.

It was an RFC, not a joke ;-)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch