Re: Pull is Evil

[Felipe Contreras <felipe.contreras@gmail.com>]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> > Matthieu Moy wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >> ...
> >> > Yes, this has been discussed many times in the past, and everyone agrees
> >> > the default behavior is not correct.
> >> 
> >> You definitely have a strange notion of "everyone".

> While I do not quite see the previous discussion as deciding the
> particular implementation is good without further tweaks, I would
> say that everybody agrees that the default behaviour is not good for
> everybody and therefore should (or for Linus, "it is OK to") change.

Yes. The only aspect I didn't see consensus is whether
'git pull $remote' should reject non-ff merges by default as well. I
argued that 'git pull $remote' shouldn't behave differently than
'git pull', but I got no responses.

> > Rational people don't think in absolute terms, "everyone" means
> > virtually everyone, which is the case.
> 
> True for "should change", not virtually everyone for "should change
> with that particular solution".

I said 'everyone agrees the default behavior is not correct', which is
true.

> But after re-reading the series description 0/n this round in the
> other thread, I think the overall direction is good (just like Peff
> said in the previous thread), especially if there is a warning not
> error period.
> 
> The step (I am not sure you have it in your series or not, but I
> would strongly recommend adding one if it doesn't yet) that gives a
> "will change the default, and here is how to configure" warning when
> we see an actual merge made (or rebased) after "git pull" without
> "--merge/--rebase" is not just a way to prepare existing users, but
> is a good way to bring new goodness to newbies.  The session might
> go like this:
> 
> 	$ git pull
>         ... fetching ...
>         ... merging ...
>         ... diffstat ...
>         warning: you merged the $branch from $remote into your
>         warning: work, which may not be what you wanted to do unless
>         warning: you are acting as a project integrator.  If that is
>         warning: the case, "git config --set pull.mode ff-only" to
>         warning: cause "git pull" to refuse working when it does not
>         warning: fast-forward.  Use pull.mode=merge if you did mean
>         warning: it, to squelch this message.
> 
> I am not advocating the exact wording above, but am illustrating
> that there is a place for us to tell the new people to live in a
> better future before the switchover happens.

As I said, I already sent a patch similar to that, but I dropped it
since this was for v2.0, and since I excepted this series to be ignored
like so many.

I'll resend.

-- 
Felipe Contreras