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

[John Keeping <john@keeping.me.uk>]

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.