On Fri, Dec 11, 2020 at 2:38 PM Alex Henrie <alexhenrie24@xxxxxxxxx> wrote: > > 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, This is what we all want, in my opinion. > and not add any new config variables But we need first to give users the ability to test this new mode with a configuration variable. It's how we get there that we disagree. > 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. No, it's not bad behavior. But we need to warn our users that this change is coming first, and how to try it out. That's what I think. Cheers. -- Felipe Contreras
