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