Matthias Baumgarten wrote: > On 7/16/21 6:44 PM, Felipe Contreras wrote: > > Elijah Newren wrote: > >> On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten > >> <matthias.baumgarten@xxxxxxxxxx> wrote: > >>> this is my first time contacting you guys and girls so I hope this mail > >>> achieves the expected standard. I've discovered the following behaviour > >>> of git: > >>> > >>> If pull.rebase is configured to true and git pull --ff-only is executed > >>> it seems like the config wins, i.e. issuing "Successfully rebased and > >>> updated refs/heads/...", which is not what I would expect. I always > >>> believed that command line options would overwrite configured options. > >>> > >>> Is my assumption that command line options always win wrong or is this a > >>> bug? > >> > >> It's a bug. > > > > No it isn't. > > > > Elijah is elevating to fact his opinion of what --ff-only should be > > changed to. > > > > But it has not been changed. Today --ff-only is meant only for the merge > > mode of `git pull`, and like other merge-only options (e.g. --ff, > > --no-ff, and --squash) it's ignored in the rebase mode. > > Shouldn't every explicitly given merge option (like --ff-only) overwrite > any configured option that would not even result in a merge, i.e. > forcing a merge and thus forcing ff-only? Perhaps. Other developers have suggested that before. The problem is that everyone wants to make --ff-only the default, and then we start to get into a tricky situation, because what should these do: git -c pull.ff=only pull git -c pull.ff=only pull --merge git -c pull.ff=only pull --rebase One of these will always fail, when it shouldn't. I proposed a solution for that, but is has been ignored. -- Felipe Contreras
