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

Felipe Contreras [off-list ref] writes:

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

quoted

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