W. Trevor King wrote: > On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote: > > W. Trevor King wrote: > > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote: > > > > It would matter almost exactly zero. > > > > > > Some folks have explicit merge policies, and deciding how much > > > that matters is probably best left up to the projects themselves > > > and not decided in Git code. > > > > Let's make some fake numbers to see around how much this would matter. > > The point isn't that this is a huge flaw, the point is that we should > be able to configure Git to match sane workflows. The point is that we are tainting a discussion about how to improve the defaults for the vast majority of users, and given Git's history, the most likely outcome is that nothing will happen, neither for the majority, nor the tiny minority. > Saying “that's unlikely to happen” doesn't solve the problem that some > newcomers have trouble matching their project's desired workflow. % git config --global pull.ff false Done. > The goal is to train them to do: > > > % git config --global pull.mode none > > % git fetch > > % git merge --no-ff > > The 'git pull' (with 'none' mode) explainer just helps retrain folks > that are already using the current 'git pull' incorrectly. If you are going to train them to use a configuration, it should be: % git config --global pull.ff false -- 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