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 [off-list ref] writes:

quoted

On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano [off-list ref] wrote:

quoted

Felipe Contreras [off-list ref] writes:

quoted

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.