Re: Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)

Marc Branchaud [off-list ref] writes:

But I'm definitely biased because I think pull is pretty much broken:

* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their expectations and they end up
starting threads like this one on the mailing list.

* If we change pull's default behaviour, we'll just be shifting the
mismatched expectations onto the other half of the new users who would be
happy with fetch-then-merge.

* I'm not sure why new users are taught to use pull.  I suspect it's because
it tries to hide the idea of local-vs-remote branches, and people writing git
tutorials don't want to overwhelm new users with what seems to be an internal
detail.  But these notions are really fundamental to using git effectively,
and I think pull does everyone a disservice by trying to gloss them over.

Anyway, rather than ranting on I'll just suggest that there's not enough
commonality between the ways people use git to make it worthwhile trying to
teach pull how to deal with a significant number of them.  I think the pull
command should be deprecated and quietly retired as a failed experiment.

I almost agree with the first sentence in the last paragraph, and
your bulletted list above supports it.

I am not sure how the second sentence can follow as its consequence.

If the conclusion were "maybe adding a 'git update' to match the
expectation of those who build on top of the work of others (aka
CVS/SVN style) more  closely and teaching new users to use that
instead of 'git pull' may be a good way forward", I can sort of
understand (if I may not be able to immediately agree with, until I
can regurgitate the ramifications of such a change) it.