Bug report

Bug report

[Alastair Douglas]

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

Re: Bug report

[Junio C Hamano]

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

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

Thanks for a report.  

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


> 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.

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.

Re: Bug report

[Alastair Douglas]

On Mon, 3 Oct 2022 at 17:53, Junio C Hamano <gitster@pobox.com> wrote:
>
> Alastair Douglas <alastair.douglas@gmail.com> writes:
>
> > I have found no solution to the issue below. Apologies if it has
> > already been addressed.
>
> Thanks for a report.
>
> The solution is to remove "[pull] rebase = preserve" and replace it
> with "[pull] rebase = merges", I think.
>

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 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.
>

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.

Re: Bug report [die() preserve-merges messages]

[Philip Oakley]

Hi Alastair,

On 04/10/2022 11:15, Alastair Douglas wrote:
> On Mon, 3 Oct 2022 at 17:53, Junio C Hamano <gitster@pobox.com> wrote:
>> Alastair Douglas <alastair.douglas@gmail.com> writes:
>>
>>> I have found no solution to the issue below. Apologies if it has
>>> already been addressed.
>> Thanks for a report.
>>
>> The solution is to remove "[pull] rebase = preserve" and replace it
>> with "[pull] rebase = merges", I think.
>>
> 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 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.
>>
> 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.

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

Re: Bug report

[Junio C Hamano]

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

> ... I feel like *something* could be updated
> to point in the right direction, but I really don't know what.

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.