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

[Junio C Hamano <gitster@pobox.com>]

John Keeping <john@keeping.me.uk> writes:

> 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 didn't mean to limit this to "with an explicit 'from where'
without 'which branch'", but it appears you took it that way.
I should have added:

    I do not think we know what we want is to affect "git pull
    origin master", either.

to clarify.  But it seems that Peff's later message in this thread
already clarifies this point for me ;-)


> 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.