Re: [PATCH 0/3] Reject non-ff pulls by default

From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Andreas Krey <a.krey@gmx.de>,
	John Keeping <john@keeping.me.uk>
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
Date: Tue, 3 Sep 2013 17:59:38 -0500	[thread overview]
Message-ID: <CAMP44s3XSVLCn7M33D4uZwUoEsY6wj34N7L8MF8bGOx0+fmV2w@mail.gmail.com> (raw)
In-Reply-To: <xmqqfvtlpm2l.fsf@gitster.dls.corp.google.com>

On Tue, Sep 3, 2013 at 5:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> Junio already sent a similar patch, but I think this is simpler.
>>>
>>> I agree that this is simpler, but I am not sure if the behaviour is
>>> necessarily better (note that this is different from saying "I think
>>> the behaviour of this patch is worse").  The motivation I read from
>>> the original discussion was that new people did "git pull" (no other
>>> parameters) to "sync my tree with the central repository" as if it
>>> were SVN, and because we are not SVN, projects that prefer rebases
>>> were unhappy, and the other one was to address *only* that use case.
>>> I do not personally like that special casing (i.e. "only when no
>>> 'integrate with what from where' is given"), and applying the "you
>>> must be explicit between rebase and merge" like this series does
>>> uniformly might (or might not) be a good thing.  I dunno.
>>
>> As I already said; there's is essentially no difference between "git
>> pull" and "git pull origin".
>
> We know what you said earlier. That does not make it right or wrong,
> but I do not think it is in line with the original discussion (that
> is why John Keeping is kept on the Cc: line).

And nobody provided any argument against that claim. People staying
silent doesn't make it wrong.

>>> The difference in changes needed to the test suite is illustrative;
>>> this series affects any use of "git pull" (with or without explicit
>>> "what to integrate with and from where"), unlike the other one that
>>> only affects the case where "git pull" was not given "what to
>>> integrate with and from where".  I think an earlier draft I did for
>>> the previous one did not special case "only when no 'integrate with
>>> what from where' is given" and had to touch all the places in the
>>> test in a similar way.
>>
>> Yeah, that version affects less, but it also doesn't achieve what we
>> actually want.
>
> I do not think we know what we want is to affect "git pull origin".

Of course we do.

What we want is to make "git pull" more user-friendly, specially to
newcomers, and specially those that come from centralized VCS, where
"tool pull" updates the checkout, and thus we want "git pull" not to
create merges inadvertently, and the best way to do that is to warn
the user that the merge is non-fast-forward, and he should do a merge
or rebase.

The fact that a particular user might have learned about remotes and
did "git pull origin" instead is irrelevant, he would still want to be
warned about non-fast-forward merges.

Everybody would want to be warned about that by default, I know I
would, I might even start using 'git pull' again, and so countless
people that have stopped using 'git pull' precisely for this reason.

-- 
Felipe Contreras