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

[Marc Branchaud <marcnarc@xiplink.com>]

On 14-04-28 02:41 PM, Junio C Hamano wrote:
> Marat Radchenko <marat@slonopotamus.org> writes:
> 
>> Problem #1: TortoiseGit GUI windows for common tasks have a heck
>> lots of controls that a common Git user will never need.
> 
> Do people around TortoiseGit lurk on this list?  Otherwise this may
> not be something we can help you with here.
> 
>> Problem #2 occured the first day we started using Git on real
>> project. It is explained in detail in older post to Git ML [3]. I
>> call it "swapped/reverse merge problem".
>>
>> In short:
>> 1. Hack, hack, hack
>> 2. Commit
>> 3. Push, woops, reject (non-ff)
>> 4. Pull
>> 5. Push
>>
>> The root of evil is step #4 that creates a merge commit with
>> "swapped" parents.
> 
> Yes, this is a real issue, and I do not mind seeing a patch to
> improve the situation (there may be different approaches, and one
> random approach somebody takes may not necessarily be a good way to
> improve the situation though).
> 
>  - Perhaps by allowing an option to tell the "pull" at the fourth
>    step to record swapped parents in the merge?
> 
>  - Perhaps in step #3, stop suggesting to "pull first" and instead
>    tell them to "fetch upstream, rebase your work on it and then
>    push"?

This approach would be my preference.

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.

		M.