Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > Junio C Hamano wrote: > ... >> Until the "--merge" option is added, "pull.mode = merge" cannot be >> the same as "git pull --merge". I think you either need to squash >> these two steps into one, or flip the order of them. > > Yeah, but the documentation of --merge should mention `pull.mode` and > `branch.<name>.pullmode`. If I do --merge first I would have to mention > pull.rebase and branch.<name>.rebase, which is weird. And the point of your step (1) to introduce pull.mode is to fix the weirdness, so in that sense, it makes even more sense to do the "--merge" first and then pull.mode the second. If you first add --merge with an awkward documentation in the first step and then correct that awkwardness in the second step that adds pull.mode (oh, by the way, we need to pay attention to pull.rename as a fallback at least for a while), that would show a clear justification why pull.mode is a good idea. > I think it's more sensible to do the less visible changes first. The people who discover pull.mode and set it to "merge" will be greeted with an error with that step. So it appears that squashing these two (and possibly also the addition of merge-ff-only) into a single step would be the only alternative, if you want to avoid the "introduce something that shows the awkwardness of the situation and immediately fix it" approach. -- 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