Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > First, the discussions on this thread show that it's hard to find the > right behavior. My guess is that it's hard because we're trying to think > for the users. I've used GNU Arch for a while, and this VCS was trying > to impose what the developer thought was good for me. I had to fight > with the tool whenever I tried to do something "non-standard". I don't > want to go back there. Fond memories of tla comes back to me as well ... ;-) > Preventing _users_ to do something because _we_ considered it was > bad for them is wrong IMHO. > I already mentionned another reason in > http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=229162 : > "git rebase" is hard to use for many people. > ... > "git pull" is one of the first things one learns with Git, and > _requiring_ users to chose between merge and rebase is a nonsense at > this time of learning. After I re-read that message, I am starting to think that the topic that has been cooking in 'next' that attempts to catch "git pull" (no "from where, integrate with what" parameters) may already be bad by that standard. Brian Carlson's comments on the impact on existing users seems to the same direction to me. You are in favor of an _option_ to allow people to forbid a pull in a non-ff situation, and I think other people are also in agreement. So perhaps: - drop jc/pull-training-wheel and revert its merge from 'next'; - update Felipe's series with a bit of tweak to make it less impactful by demoting error into warning and advice. would be a good way forward? -- 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