git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: pull.rebase config vs. --ff-only on command line

From
MBMatthias Baumgarten <matthias.baumgarten@aixigo.com>
Date
Jul 19, 2021, 14:26 UTC
Message-ID
<fa757764-db25-849d-d8d5-e28908059f6b@aixigo.com>
In-Reply-To
<60f1c9378d5a1_3302085c@natae.notmuch>
On 7/16/21 8:00 PM, Felipe Contreras wrote:
Show 41 quoted lines
> 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@aixigo.com> 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

If my assumption were true, and every explicit (cli given) option would overwrite implicitly given ones (i.e. configured options), wouldn't

  * git -c pull.ff=only pull, do a fast-forward (or merge)
  * git -c pull.ff=only pull --merge, force a merge commit
  * git -c pull.ff=only pull --rebase, force rebase
> 
> One of these will always fail, when it shouldn'tWould this even apply under the above assumption?
> 
> I proposed a solution for that, but is has been ignored.
I'm sorry!
> 
-- 
aixigo AG
Karl-Friedrich-Str. 68, 52072 Aachen, Germany
phone: +49 (0)241 559709-390, fax: +49 (0)241 559709-99
email: matthias.baumgarten@aixigo.com
web: https://www.aixigo.com
District Court Aachen – HRB 8057
Board: Christian Friedrich, Tobias Haustein
Chairman of the Supervisory Board: Dr. Roland Schlager
Previous: Felipe ContrerasNext: Felipe Contreras
Message 6 of 11 in “pull.rebase config vs. --ff-only on command line”
  1. Matthias BaumgartenJul 16, 2021
  2. Elijah NewrenJul 16, 2021
  3. Felipe ContrerasJul 16, 2021
  4. Matthias BaumgartenJul 16, 2021
  5. Felipe ContrerasJul 16, 2021
  6. Matthias BaumgartenJul 19, 2021
  7. Felipe ContrerasJul 19, 2021
  8. Junio C HamanoJul 22, 2021
  9. Felipe ContrerasJul 22, 2021
  10. Matthias BaumgartenJul 23, 2021
  11. Felipe ContrerasJul 16, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.