Philip Oakley <philipoakley@iee.email> 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.
