Re: [BUG] git pull --rebase ignores rebase.autostash config when fast-forwarding

[Tilman Vogel <tilman.vogel@web.de>]

Oh, please excuse my lack of providing the version info: I discovered
the behaviour on 2.34.1 as shipped by current openSUSE Tumbleweed.
Then, I worked on-top of current git master (2ae0a9cb).

Regards and thanks for investigating and fixing this so quickly!

Tilman


Am Di., 4. Jan. 2022 um 19:03 Uhr schrieb Philippe Blain
<levraiphilippeblain@gmail.com>:
>
> Hi Tilman,
>
> Le 2022-01-04 à 07:59, Philip Oakley a écrit :
> > On 03/01/2022 18:08, Tilman Vogel wrote:
> >> Hi git-people,
> >>
> >> I ran into strange behavior when having rebase.autostash enabled and
> >> doing a git pull --rebase:
> >>
> >>> git config rebase.autostash true
> >>> git pull --rebase
> >> Updating cd9ff8a..f3c9840
> >> error: Your local changes to the following files would be overwritten by
> >> merge:
> >>          content
> >> Please commit your changes or stash them before you merge.
> >> Aborting
> >>
> >> Confusingly, this fixes the issue:
> >>
> >>> git config merge.autostash true
> >>> git pull --rebase
> >> Updating cd9ff8a..f3c9840
> >> Created autostash: c615fda
> >> Fast-forward
> >>   content | 1 +
> >>   1 file changed, 1 insertion(+)
> >> Applied autostash.
> >>
> >> Leaving me wonder why merge config options fix rebase behavior.
> >>
> >> So, in order to make it easier to check the problem, I added some
> >> test-cases to the git test-suite. Please see the attached patch.
>
> Thanks, this really makes it easier to bisect the issue.
>
> >>
> >> Or here:
> >> https://github.com/tvogel/git/commit/bc941f9357518a34cfa11788dfb8e7fa7f711705
> >>
> >> I did not try to find the root-cause as I am not experienced with the
> >> code-base but if there are questions, let me know.
> >
> > Which version are you running?
> >
>
> That's a good info to include indeed. I'm guessing you are using v2.34.1 as that's the version
> indicated at the bottom of your attached patch. I can replicate the behaviour on my side on 2.34.1.
> I did not bisect manually but I'm pretty sure it's a regression caused by 340062243a (pull: cleanup autostash
> check, 2021-06-17) (author CC'ed). I checked that the parent of that commit passes all 4 of your added tests, provided
> this is squashed in:
>
> diff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh
> index 4046a74cad..5ad19b1028 100755
> --- a/t/t5521-pull-options.sh
> +++ b/t/t5521-pull-options.sh
> @@ -260,7 +260,6 @@ test_expect_success 'git pull --rebase --autostash succeeds on ff' '
>         test_commit -C src --printf "more_content" file "more content\ncontent\n" &&
>         echo "dirty" >>dst/file &&
>         git -C dst pull --rebase --autostash >actual 2>&1 &&
> -       grep -q "Fast-forward" actual &&
>         grep -q "Applied autostash." actual
>   '
>
> @@ -273,7 +272,6 @@ test_expect_success 'git pull --rebase with rebase.autostash succeeds on ff' '
>         echo "dirty" >>dst/file &&
>         test_config -C dst rebase.autostash true &&
>         git -C dst pull --rebase  >actual 2>&1 &&
> -       grep -q "Fast-forward" actual &&
>         grep -q "Applied autostash." actual
>   '
>
> After that commit, in case of fast-forward, 'git pull --rebase --autostash' delegates the fast-forward
> operation to 'git merge' under the hood, which was not the case before. The '--autostash' flag seems
> to be forwarded correctly to that 'git merge' invocation, but the config 'rebase.autostash' seems to not
> be passed along.
>
> I did not yet look into why in the code itself. That does explain however why 'merge.autostash' makes it
> work - the 'git merge' invocation does check its own config, and if merge.autostash is there the autostash
> behaviour is activated.
>
> Philippe.
>
>