Re: [PATCH v2 3/4] rebase: note `preserve` merges may be a pull config option
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 11, 2022, 19:22 UTC
- Message-ID
- <xmqqh74rattu.fsf@gitster.g>
- In-Reply-To
- <3800fa9c-50b4-2967-2f00-036c1edf5e52@iee.email>
Philip Oakley <philipoakley@iee.email> writes:
Show 16 quoted lines
> 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?
Show 5 quoted lines
>> 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.