Subject: Re: [PATCH v2 3/4] rebase: note `preserve` merges may be a pull config option

From: Junio C Hamano <[email-masked]>
Date: Sat, 11 Jun 2022 12:22:37 -0700

Philip Oakley <[email-masked]> writes:

> small clarification,
>
> On 11/06/2022 15:03, Philip Oakley wrote:
>>> When pull.rebase is parsed, rebase.c::rebase_parse_value() is called
>>> from builtin/pull.c::parse_config_rebase() and would trigger an
>>> error, whether it comes from the pull.rebase or the branch.*.rebase
>>> configuration variable.  An error() message already said that
>>> 'preserve' was removed and 'merges' would be a replacement when it
>>> happened.
>>>
>>> If the user has *not* reached this die() due to a configuration
>>> variable, then there is not much point giving this new message,
>>> either.
>> From my perspective, users should then
>
> That is, when users hit any of the `preserve-merges` error message, ... 

Yes, but configuration parsing happens way earlier than the actual
use of the option (which is decided after configuration and then
command line is read), so the users would probably have hit the
error message and corrected their configuration before they can even
see this error message, no?

I guess I am repeating myself, so there may be some case where a
stale variable can still be in the user's configuration file and the
user can hit this error message without seeing the other error
message about the stale configuration variable that I am not seeing?

>>  be purging _all_ their `preserve`
>> configurations once they hit such errors. As the v2.34.0 change
>> propagates through the Git ecosystem, hopefully it'll be a sufficient
>> prompt for those who haven't realised that the option can be 'hidden' in
>> their configuration options.