On Wed, Dec 2, 2020 at 7:21 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > So, the idea is that we currently return NULL when pull.ff is set, > but now we also check "pull.rebase" etc. and give "--ff-only" when > we did not choose --[no-]rebase and lack the configuration. So the > default (i.e. when pull.ff and pull.rebase are not set) would be as > if the user said > > git pull --ff-only --no-rebase > > I am not seeing what problem this tries to solve, exactly, though. > > I would have expected that for those who did not choose between > merge and rebase (either with the pull.rebase configuration or from > the command line --[no-]rebase option) the command would behave as > if --ff-only is given, regardless of how pull.ff configuration is > set. That way, those who are unconfigured will just follow along > what happens at the upstream, until they have their own development, > at which point "--ff-only" can no longer be satisfied and their > "pull" would fail until they choose how to consolidate their work > with the upstream. My goal was to make `git pull` without arguments and without any configuration set (the most common case) reject non-fast-forwards, and not add any new config variables or substantially change the semantics of the existing ones. In my opinion it's fine that setting pull.ff would change the behavior of `git pull` without arguments; I don't think that that would be bad behavior. I am glad to see so much discussion surrounding the behavior of and documentation for `git pull`, but unfortunately at this point I'm having trouble following the discussion as a whole. I'm hoping that it settles down some so that it becomes more clear what I can do to help. -Alex
