Re: Pull is Mostly Evil

From: David Lang <david@lang.hm>
Date: May 2, 2014, 19:31 UTC
Message-ID: <alpine.DEB.2.02.1405021227161.14881@nftneq.ynat.uz>
In-Reply-To: <87k3a4xjzg.fsf@fencepost.gnu.org>

On Fri, 2 May 2014, David Kastrup wrote:

Show 14 quoted lines

> Date: Fri, 02 May 2014 17:45:23 +0200
> From: David Kastrup <dak@gnu.org>
> To: git@vger.kernel.org
> Subject: Re: Pull is Mostly Evil
> 
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> To that end, I suggest that pull's default behaviour should be to do
>> *nothing*.  It should just print out a message to the effect that it
>> hasn't been configured, and that the user should run "git help pull"
>> for guidance.
>
> Fetching is uncontentious, and I _think_ that fast-forwards are pretty
> uncontentious as well.

so those people just need to use fetch instead of pull.

This seems fairly straightforward

fetch, get the data but don't integrate it

pull, get the data and ff along it if possible

pull with options, merge/rebase left/right based on options when ff is not possible.

Pull was created with one workflow in mind, Changing it to require explcitly specifying the option (in a config, with appropriate transition, handholding) is not completly unreasonable, and given the confusion this causes, may be very reasonable.

But saying that ff isn't always right, so make pull go away altogether (or "don't change anything because there isn't 100% agreement on the result" paralysis) doesn't seem right.

> It's just when the merge-left/merge-right/rebase-left/rebase-right
> decision kicks in that prescribing one git-pull behavior looks like a
> recipe for trouble.

confusion at least. It's not fatal confusion, people have been using it for years after all.

David Lang