Johannes Schindelin [off-list ref] writes:
On Tue, 9 Nov 2021, Junio C Hamano wrote:
quoted
* jc/fix-pull-ff-only-when-already-up-to-date (2021-10-29) 1 commit
(merged to 'next' on 2021-10-29 at ad4753e668)
+ pull: --ff-only should make it a noop when already-up-to-date
"git pull --ff-only" and "git pull --rebase --ff-only" should make
it a no-op to attempt pulling from a remote that is behind us, but
instead the command errored out by saying it was impossible to
fast-forward, which may technically be true, but not a useful thing
to diagnose as an error. This has been corrected.
Will cook in 'next'.
I would like to register a vote for advancing this into v2.34.0,
still.
I didn't recall I did it as a regression fix, but as a fix for
relatively old change that is already in released version(s) in the
field. If the breakage is new between 2.33.0 and 'master', I think
it is a good idea to merge it down.
Thanks.
On Wed, Nov 10, 2021 at 10:21 AM Junio C Hamano [off-list ref] wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Tue, 9 Nov 2021, Junio C Hamano wrote:
quoted
* jc/fix-pull-ff-only-when-already-up-to-date (2021-10-29) 1 commit
(merged to 'next' on 2021-10-29 at ad4753e668)
+ pull: --ff-only should make it a noop when already-up-to-date
"git pull --ff-only" and "git pull --rebase --ff-only" should make
it a no-op to attempt pulling from a remote that is behind us, but
instead the command errored out by saying it was impossible to
fast-forward, which may technically be true, but not a useful thing
to diagnose as an error. This has been corrected.
Will cook in 'next'.
I would like to register a vote for advancing this into v2.34.0,
still.
I didn't recall I did it as a regression fix, but as a fix for
relatively old change that is already in released version(s) in the
field. If the breakage is new between 2.33.0 and 'master', I think
it is a good idea to merge it down.
For what it's worth, I also consider this to be a (small) regression
introduced in 2.33.0. So I'd also like to vote for fixing it in 2.34.
-Alex
Hi Junio,
On Wed, 10 Nov 2021, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Tue, 9 Nov 2021, Junio C Hamano wrote:
quoted
* jc/fix-pull-ff-only-when-already-up-to-date (2021-10-29) 1 commit
(merged to 'next' on 2021-10-29 at ad4753e668)
+ pull: --ff-only should make it a noop when already-up-to-date
"git pull --ff-only" and "git pull --rebase --ff-only" should make
it a no-op to attempt pulling from a remote that is behind us, but
instead the command errored out by saying it was impossible to
fast-forward, which may technically be true, but not a useful thing
to diagnose as an error. This has been corrected.
Will cook in 'next'.
I would like to register a vote for advancing this into v2.34.0,
still.
I didn't recall I did it as a regression fix, but as a fix for
relatively old change that is already in released version(s) in the
field. If the breakage is new between 2.33.0 and 'master', I think
it is a good idea to merge it down.
I can say with conviction that this is a very recent change of behavior,
as I needed this quick-fix on Oct 30:
https://github.com/git-for-windows/build-extra/commit/fb311a97cf82243ea1fe4036f1b180f5a3e6bc7f
I don't recall the particular details how this fix came about, as it was
the day of -rc0 (and I don't remember whether I needed this _before_ or
_after_ Git for Windows -rc0 was released). All I remember is that an
automated build broke because it created a local commit and then expected
`git pull --ff-only` to succeed (because the remote was not ahead, but it
necessarily was behind the local HEAD).
The change of behavior might have been introduced by v2.33.1, or by
v2.34.0-rc0.
So yeah, I would argue that it is a regression introduced in this cycle.
Ciao,
Dscho