Jacob Keller <jacob.keller@xxxxxxxxx> writes: > I think the key point is that this "in the future" is referring to "a > future version of git will make this an error" > > This might be better if it said something like "The pull was not > fast-forward. In a future version of git you will need to specify > whether to merge or rebase, using pull.mode" Oh, I've actually been assuming that the current "warn but go ahead anyway asssuming the preference is to merge" can just be declared as a bug (iow, there is no need to say 'in the future'---we'd fix the bug right away). > or something similar. In theory, this warning will go away once that > future version of git changes so that pull.mode defaults to ff-only. > > The difference being that a warning will allow the command to continue > doing the default of today (merging), where as an error will stop the > command essentially just after the fetch portion finishes, without > changing the branch. Yup. If we want to take things slow, that is fine by me as well, but I am not sure if that is even necessary, given how annoying the existing "loudly warn but still go ahead" behaviour is, and how easy for existing users to have squelched the annoyance by choosing between rebase and merge already. I've always assumed that any existing users who started using Git in the past several years have already set pull.rebase to one or the other value and they won't be affected by fixing "git pull" to just error out.
