Junio C Hamano wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
> > Matthieu Moy wrote:
> >> Felipe Contreras <felipe.contre...@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
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html