* pull.rebase config vs. --ff-only on command line @ 2021-07-16 14:43 Matthias Baumgarten 2021-07-16 15:03 ` Elijah Newren 2021-07-16 16:39 ` Felipe Contreras 0 siblings, 2 replies; 11+ messages in thread From: Matthias Baumgarten @ 2021-07-16 14:43 UTC (permalink / raw) To: git@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pull.rebase config vs. --ff-only on command line 2021-07-16 14:43 pull.rebase config vs. --ff-only on command line Matthias Baumgarten @ 2021-07-16 15:03 ` Elijah Newren 2021-07-16 16:44 ` Felipe Contreras 2021-07-16 16:39 ` Felipe Contreras 1 sibling, 1 reply; 11+ messages in thread From: Elijah Newren @ 2021-07-16 15:03 UTC (permalink / raw) To: Matthias Baumgarten; +Cc: git@vger.kernel.org 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pull.rebase config vs. --ff-only on command line 2021-07-16 15:03 ` Elijah Newren @ 2021-07-16 16:44 ` Felipe Contreras 2021-07-16 16:54 ` Matthias Baumgarten 0 siblings, 1 reply; 11+ messages in thread From: Felipe Contreras @ 2021-07-16 16:44 UTC (permalink / raw) To: Elijah Newren, Matthias Baumgarten; +Cc: git@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pull.rebase config vs. --ff-only on command line 2021-07-16 16:44 ` Felipe Contreras @ 2021-07-16 16:54 ` Matthias Baumgarten 2021-07-16 18:00 ` Felipe Contreras 0 siblings, 1 reply; 11+ messages in thread From: Matthias Baumgarten @ 2021-07-16 16:54 UTC (permalink / raw) To: Felipe Contreras, Elijah Newren; +Cc: git@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pull.rebase config vs. --ff-only on command line 2021-07-16 16:54 ` Matthias Baumgarten @ 2021-07-16 18:00 ` Felipe Contreras 2021-07-19 14:26 ` Matthias Baumgarten 0 siblings, 1 reply; 11+ messages in thread From: Felipe Contreras @ 2021-07-16 18:00 UTC (permalink / raw) To: Matthias Baumgarten, Felipe Contreras, Elijah Newren; +Cc: git@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pull.rebase config vs. --ff-only on command line 2021-07-16 18:00 ` Felipe Contreras @ 2021-07-19 14:26 ` Matthias Baumgarten 2021-07-19 17:43 ` Felipe Contreras 2021-07-22 18:57 ` Junio C Hamano 0 siblings, 2 replies; 11+ messages in thread From: Matthias Baumgarten @ 2021-07-19 14:26 UTC (permalink / raw) To: Felipe Contreras, Elijah Newren; +Cc: git@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pull.rebase config vs. --ff-only on command line 2021-07-19 14:26 ` Matthias Baumgarten @ 2021-07-19 17:43 ` Felipe Contreras 2021-07-22 18:57 ` Junio C Hamano 1 sibling, 0 replies; 11+ messages in thread From: Felipe Contreras @ 2021-07-19 17:43 UTC (permalink / raw) To: Matthias Baumgarten, Felipe Contreras, Elijah Newren; +Cc: git@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pull.rebase config vs. --ff-only on command line 2021-07-19 14:26 ` Matthias Baumgarten 2021-07-19 17:43 ` Felipe Contreras @ 2021-07-22 18:57 ` Junio C Hamano 2021-07-22 22:09 ` Felipe Contreras 2021-07-23 9:36 ` Matthias Baumgarten 1 sibling, 2 replies; 11+ messages in thread From: Junio C Hamano @ 2021-07-22 18:57 UTC (permalink / raw) To: Matthias Baumgarten; +Cc: Felipe Contreras, Elijah Newren, git@vger.kernel.org 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pull.rebase config vs. --ff-only on command line 2021-07-22 18:57 ` Junio C Hamano @ 2021-07-22 22:09 ` Felipe Contreras 2021-07-23 9:36 ` Matthias Baumgarten 1 sibling, 0 replies; 11+ messages in thread From: Felipe Contreras @ 2021-07-22 22:09 UTC (permalink / raw) To: Junio C Hamano, Matthias Baumgarten Cc: Felipe Contreras, Elijah Newren, git@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: pull.rebase config vs. --ff-only on command line 2021-07-22 18:57 ` Junio C Hamano 2021-07-22 22:09 ` Felipe Contreras @ 2021-07-23 9:36 ` Matthias Baumgarten 1 sibling, 0 replies; 11+ messages in thread From: Matthias Baumgarten @ 2021-07-23 9:36 UTC (permalink / raw) To: Junio C Hamano; +Cc: Felipe Contreras, Elijah Newren, git@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: pull.rebase config vs. --ff-only on command line 2021-07-16 14:43 pull.rebase config vs. --ff-only on command line Matthias Baumgarten 2021-07-16 15:03 ` Elijah Newren @ 2021-07-16 16:39 ` Felipe Contreras 1 sibling, 0 replies; 11+ messages in thread From: Felipe Contreras @ 2021-07-16 16:39 UTC (permalink / raw) To: Matthias Baumgarten, git@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-07-23 9:43 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-16 14:43 pull.rebase config vs. --ff-only on command line Matthias Baumgarten 2021-07-16 15:03 ` Elijah Newren 2021-07-16 16:44 ` Felipe Contreras 2021-07-16 16:54 ` Matthias Baumgarten 2021-07-16 18:00 ` Felipe Contreras 2021-07-19 14:26 ` Matthias Baumgarten 2021-07-19 17:43 ` Felipe Contreras 2021-07-22 18:57 ` Junio C Hamano 2021-07-22 22:09 ` Felipe Contreras 2021-07-23 9:36 ` Matthias Baumgarten 2021-07-16 16:39 ` Felipe Contreras
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).