From: Philip Oakley <philipoakley@iee.email>
To: Alastair Douglas <alastair.douglas@gmail.com>,
Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Bug report [die() preserve-merges messages]
Date: Tue, 4 Oct 2022 17:53:47 +0100 [thread overview]
Message-ID: <4e457155-38d2-4d34-2240-0d2f103004a1@iee.email> (raw)
In-Reply-To: <CADTs3HFZjX7P=n3PpjAtt=6E9m3PUgFKXksZKuOY4t71hSSnrw@mail.gmail.com>
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
next prev parent reply other threads:[~2022-10-04 16:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-03 15:28 Bug report Alastair Douglas
2022-10-03 16:53 ` Junio C Hamano
2022-10-04 10:15 ` Alastair Douglas
2022-10-04 16:53 ` Philip Oakley [this message]
2022-10-05 5:46 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4e457155-38d2-4d34-2240-0d2f103004a1@iee.email \
--to=philipoakley@iee.email \
--cc=alastair.douglas@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).