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

> On Tue, Sep 03, 2013 at 03:38:58PM -0700, Junio C Hamano 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).
>
> I think there are two distinct uses for pull, which boil down to:
>
>     (1) git pull
>     (2) git pull $remote $branch
>
> For (1) a merge is almost always the wrong thing to do since it will be
> backwards and break --first-parent.
>
> But for (2) a merge is almost always the correct thing to do (in fact it
> may even be correct to create a merge commit even when this fast
> forwards) because this most likely comes for a pull request workflow.
>
>> I do not think we know what we want is to affect "git pull origin".

> I consider "git pull $remote" to be an artifact of the way git-pull is
> implemented on top of git-fetch; perhaps I'm missing something but I
> can't see a scenario where this is useful.  In the series currently in
> "next", we treat this as (2) above but that's primarily because it is
> difficult to differentiate these in git-pull.sh without adding code to
> understand all of the options to git-fetch (or at least those that can
> accept unstuck arguments).
>
> Changing this so that "git pull $remote" is treated as (1) would be
> better, but I think it is more important to avoid catching case (1) in
> the same net which is why jc/pull-training-wheel simply checks if "$#"
> is zero; the cost of getting this completely right outweighed the
> benefit of getting code in that will catch 99% of users.