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

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

[Matthias Baumgarten]

Hi,

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?

Best regards,
Matthias

-- 
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

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

[Elijah Newren]

On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten
<matthias.baumgarten@aixigo.com> wrote:
>
> Hi,
>
> 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.

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

[Felipe Contreras]

Hello Matthias,

Matthias Baumgarten 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?

Yes, your assumption is correct, but the equivalent of that combination
is:

  git pull --rebase --ff-only

But --ff-only is only meant for the merge mode of `git pull`
(git pull --merge), not the rebase mode, so it's ignored. You can see
that from the documentation [1]:

  With --ff-only, resolve the merge as a fast-forward when possible.
  When not possible, refuse to merge and exit with a non-zero status.

Note the *merge* part.

[1] https://git-scm.com/docs/git-pull

-- 
Felipe Contreras

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

[Felipe Contreras]

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.

-- 
Felipe Contreras

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

[Matthias Baumgarten]

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?

-- 
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

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

[Felipe Contreras]

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

One of these will always fail, when it shouldn't.

I proposed a solution for that, but is has been ignored.

-- 
Felipe Contreras

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

[Matthias Baumgarten]

On 7/16/21 8:00 PM, Felipe Contreras wrote:
> 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

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

[Felipe Contreras]

Matthias Baumgarten wrote:
> On 7/16/21 8:00 PM, Felipe Contreras wrote:
> > 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

The documentation says --ff-only is meant for merges, therefore these
three should be valid and do the same:

  git pull --ff-only # --merge is the default
  git pull --merge --ff-only
  git pull --ff-only --merge

In order for your assumption above to be correct, the semantics of
--ff-only have to be changed (along with the documentation), but people
are *already* relying on the current semantics:

  [pull]
    ff = only
    rebase = true

I made a poll on reddit [1], and 19% (so far) said they do use both
configurations, and they know what `git pull --no-rebase` would do.

In other words: they would expect `git pull` to do a rebase, but
`git pull --merge` to do a fast-forward merge.

Changing the semantics of --ff-only would break behavior they rely on,
unless we break symmetry from --ff-only and pull.ff=only which would be
very hard to explain the documentation.


However, if --ff-only wasn't mapped to pull.ff=only, but
pull.mode=fast-forward, then we can have both: the configurations people
rely on today wouldn't be broken, and your expectation that
`git pull --ff-only` overrides pull.mode=rebase would be met.

It's the perfect solution.

> > One of these will always fail, when it shouldn't
> Would this even apply under the above assumption?

[I think you meant to paste this]

Under your assumption it wouldn't fail, but other behavior users rely on
today would be broken.

> > I proposed a solution for that, but is has been ignored.
> I'm sorry!

It's not me the one that suffers (I don't even use `git pull`), it's the
users that have been negatively affected for more than ten years.

[1] https://www.reddit.com/r/git/comments/omcngl/do_you_use_both_pullff_and_pullrebase/

-- 
Felipe Contreras

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

[Junio C Hamano]

Matthias Baumgarten <matthias.baumgarten@aixigo.com> writes:

> 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)

This should fast-forward if it can or otherwise fail if it cannot,
right?

>  * git -c pull.ff=only pull --merge, force a merge commit

This would fast-forward if it can or otherwise create a merge.
Unlike "pull --no-ff", this should not "force" a merge commit.

>  * git -c pull.ff=only pull --rebase, force rebase

This would rebase (we may not have our own commits on top of theirs,
in which case it would end up fast-forwarding plus rebasing 0
commits).

I do not think the phrase "force rebase" makes much sense, though.

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

[Felipe Contreras]

Junio C Hamano wrote:
> Matthias Baumgarten <matthias.baumgarten@aixigo.com> writes:

> >  * git -c pull.ff=only pull --merge, force a merge commit
> 
> This would fast-forward if it can or otherwise create a merge.
> Unlike "pull --no-ff", this should not "force" a merge commit.

Today people rely on this doing a fast-forward-only merge (with
--no-rebase).

Changing this would break existing behavior they rely on.

It's not hypothetical [1].

[1] https://www.reddit.com/r/git/comments/omcngl/do_you_use_both_pullff_and_pullrebase/

-- 
Felipe Contreras

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

[Matthias Baumgarten]

On 7/22/21 8:57 PM, Junio C Hamano wrote:
>>   * git -c pull.ff=only pull, do a fast-forward (or merge)
> 
> This should fast-forward if it can or otherwise fail if it cannot,
> right?

Yes, I should not have written "... (or merge)".

>>   * git -c pull.ff=only pull --merge, force a merge commit
> 
> This would fast-forward if it can or otherwise create a merge.
> Unlike "pull --no-ff", this should not "force" a merge commit.

Ack. I.e. it should work like "git merge" would by default.

>>   * git -c pull.ff=only pull --rebase, force rebase
> 
> This would rebase (we may not have our own commits on top of theirs,
> in which case it would end up fast-forwarding plus rebasing 0
> commits).

Yes. Again, this should and would behave like e.g. "git rebase" would if 
I were to rebase a branch which is a few commits _behind_ the branch I 
rebase on top of.

> I do not think the phrase "force rebase" makes much sense, though.
Agree.


-- 
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