Vít Ondruch <vondruch@xxxxxxxxxx> writes: > While I understand that the merge after `git pull` is probably not the > best strategy (as explained in [1]), asking people to change their > configuration to choose their default strategy with every `git pull` > is not any better. There is no clear "default that would suit everybody". There are many people for whom 'rebase' is totally a wrong thing in their 'pull', and there are many people for whom 'merge' is totally a wrong thing in their 'pull'. Worse, because a user does not necessarily play the same role in multiple projects, even the same human user may want to use 'rebase' while working on some projects while 'merge' is preferred on other projects. And the userbase of Git is large enough that it is no longer a viable approach to say "which group has more people? pick the one that is better to them" unless we are dealing with a _new_ feature. Even 1% minority of the userbase is still a large number in absolute terms. That is why pull.rebase=(yes|no) exists to serve people with either workflow to record preference just once for the repository with "git config" and "git pull" would stop asking in the repository. When they always prefer one way, they can even run "git config --global" just once and the setting applies to all of their repositories, stopping "git pull" from asking in any repository.
