Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > That is exemplified by the fact that this whole thread started from a > user that refused to configure pull.rebase and expected the Git > project to just do the right thing (which is basically choosing a > useful default). Which is basically asking for impossible, and I do not think it is a good idea to focus our effort to satisfy such a request in general. There is no useful default that suits everybody in this particular case. The "force ff-only" approach indeed gives a very sensible default behaviour of dying for those who haven't expressed the choice between rebase and merge in a situation where the difference between the two results in histories of different shapes. But for anybody who uses git for real (read: produces his or her own history), it would be pretty much a useless default that forces the user to say rebase or merge every time 'git pull' is run. That is why I am not enthused by the pull.mode=(rebase/merge/ff-only) configuration. The third choice does help completeness. When a user asks "the documentation tells pull.mode can be set to non-default behaviour---what value can one set it to to get the default behaviour of not allowing any original work?", it can be answered if we had pull.mode=ff-only. But other than that, I do not see any real use for the choice, which would mean in practice, pull.mode would have only two useful values, rebase or merge. That does not feel a good enough reason to supersede what already exists, which is pull.rebase=yes/no. Perhaps there is a good reason why certain classes of users would want to configure pull.mode=ff-only (i.e. "I might type 'git pull' by mistake, please stop me if I did so on a branch I have real work already."). If that is the case, I would very much agree that it would be awkward to express that choice in the current framework to choose between pull.rebase=yes/no and pull.mode=(rebase/merge/ff-only) would become a lot easier to explain. I dunno.
