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
On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten
[off-list ref] 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?
From: Felipe Contreras <hidden> Date: 2021-07-16 16:39:14
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
From: Felipe Contreras <hidden> Date: 2021-07-16 16:44:57
Elijah Newren wrote:
On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten
[off-list ref] wrote:
quoted
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
On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten
[off-list ref] wrote:
quoted
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
From: Felipe Contreras <hidden> Date: 2021-07-16 18:00:29
Matthias Baumgarten wrote:
On 7/16/21 6:44 PM, Felipe Contreras wrote:
quoted
Elijah Newren wrote:
quoted
On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten
[off-list ref] wrote:
quoted
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
On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten
[off-list ref] wrote:
quoted
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
From: Felipe Contreras <hidden> Date: 2021-07-19 17:49:37
Matthias Baumgarten wrote:
On 7/16/21 8:00 PM, Felipe Contreras wrote:
quoted
Matthias Baumgarten wrote:
quoted
On 7/16/21 6:44 PM, Felipe Contreras wrote:
quoted
Elijah Newren wrote:
quoted
On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten
[off-list ref] wrote:
quoted
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.
quoted
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.
quoted
I proposed a solution for that, but is has been ignored.
From: Junio C Hamano <hidden> Date: 2021-07-22 18:57:23
Matthias Baumgarten [off-list ref] 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.
* 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)".
quoted
* 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.
quoted
* 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