Bug report

I have found no solution to the issue below. Apologies if it has already been addressed.

What did you do before the bug happened? (Steps to reproduce your issue)

Have an existing git config with rebase = preserve

What did you expect to happen? (Expected behaviour)

Merges to be preserved when rebasing, without a warning about an option I am not using.

What happened instead? (Actual behaviour)

I received a warning as though I had used the option on the command line:

warning: git rebase --preserve-merges is deprecated. Use --rebase-merges instead.

I didn't do that, so I can't follow the advice. There appears to be no alternative config setting for the new option.

What's different between what you expected and what actually happened?

I expected rebase=preserve to now use --rebase-merges instead of --preserve-merges, or for a new config setting to be made available to use --rebase-merges. Ideally the first, because the semantics are clear.

Anything else you want to add:

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.34.1 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 5.15.0-47-generic #51-Ubuntu SMP Thu Aug 11 07:51:15 UTC 2022 x86_64 compiler info: gnuc: 11.2 libc info: glibc: 2.35 $SHELL (typically, interactive shell): /usr/bin/zsh

[Enabled Hooks] not run from a git repository - no hooks to show

Alastair Douglas <alastair.douglas@gmail.com> writes:

Thanks for a report.  

The solution is to remove "[pull] rebase = preserve" and replace it with "[pull] rebase = merges", I think.

It sounds like splitting hairs, but I agree that the message is misleading. I think whoever wrote the message meant that "the feature that is triggered by giving the --preserve-merges option to the command" was deprecated. IOW, they did not mean that only the command line option was depreated, implying that it is not deprecated to trigger the same feature by setting a configuration variable. Both forms of the use of the same feature was deprecated about the same time.

I also suspect that they were hoping that the users will read the instruction based on these command line options and understand that it also applies to the configuration variables.

On Mon, 3 Oct 2022 at 17:53, Junio C Hamano <gitster@pobox.com> wrote:

Thanks for this reply. This seems to have worked, since I got no warning.

Now that I know it is a new option to the rebase setting I have found it in the documentation:

branch.<name>.rebase
...
  When merges, pass the --rebase-merges option to git rebase so that
the local merge commits are included in the rebase (see git-rebase(1)
for details).
  When preserve (deprecated in favor of merges), also pass
--preserve-merges along to git rebase so that locally committed merge
commits will not be flattened by running git pull.

It does seem like nobody else on the internet is aware of this, since I didn't discover this by Googling it.

I understood immediately that it applied to the config, but I couldn't find a single thing about what I *should* have done until you told me here.

Having said all this, I am fairly sure that I checked the documentation for the rebase config and failed to spot that new part, so I am not blameless myself! I feel like *something* could be updated to point in the right direction, but I really don't know what. Yesterday, I genuinely thought there was no replacement config for the deprecated one!

Thanks for your time, but I suppose, in conclusion, there's not a lot to be done.

Hi Alastair,

On 04/10/2022 11:15, Alastair Douglas wrote:

Earlier this year, I tried to update the error messages to catch the various ways that the removal of 'preserve-merges' could be confusing to users, based on a Git for Windows user's report [1,2].

It is rare for a method to be removed, so there was little experience of how best to handle all the different use cases.

In general, the approach was to ensure that users could not fail to notice that something had changed, or needed to be changed. The problem with 'preserve-merges' being that there were scenarios where the code did the wrong thing and users were not noticing, and further it wasn't clear to users which case that was, nor how to explain it, given the mind-set confusions!

In general Git avoids rolling over old options to new variants, without notification, if they do different things. It would have been nice to cover more use cases, but often the cause was not known at the point the problem was detected in the code, as you have seen.

It was expected that users should have been aware of their own configuration settings, though that's not always true (see the mailing list discussions).

Philip

[1]
https://lore.kernel.org/git/pull.1155.git.1645526016.gitgitgadget@gmail.com/
 Subject: [PATCH 0/2] Update the die() preserve-merges messages to help
some users   22 Feb 2022
[2]
https://lore.kernel.org/git/pull.1242.v2.git.1654341469.gitgitgadget@gmail.com/
Subject: [PATCH v2 0/4] Die preserve ggg   04 Jun 2022

Alastair Douglas <alastair.douglas@gmail.com> writes:

Yes, I shared the exact feeling. Perhaps the message could have been a bit more helpful by referring to configuration variables that are potentially relevant.

Thanks.