Denton Liu <[email protected]> writes:
> When get_cleanup_mode was provided with an invalid cleanup_arg, it used
> to die. Warn user and fallback to default behaviour if an invalid
> cleanup_arg is given.
>
> Signed-off-by: Denton Liu <[email protected]>
> ---
> sequencer.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index 5c04bae7ac..f9bdfa90ad 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -502,8 +502,11 @@ enum commit_msg_cleanup_mode get_cleanup_mode(const char
> *cleanup_arg,
> else if (!strcmp(cleanup_arg, "scissors"))
> return use_editor ? COMMIT_MSG_CLEANUP_SCISSORS :
> COMMIT_MSG_CLEANUP_SPACE;
> - else
> - die(_("Invalid cleanup mode %s"), cleanup_arg);
> + else {
> + warning(_("Invalid cleanup mode %s, falling back to default"),
> cleanup_arg);
> + return use_editor ? COMMIT_MSG_CLEANUP_ALL :
> + COMMIT_MSG_CLEANUP_SPACE;
> + }
> }
In what different contexts does this get called, I wonder?
I think
$ git cherry-pick --cleanup=bogus ...
should error out, instead of falling back to anything else, while
having
[commit] cleanup = bogus
in .git/config should *not* say anything if you are not running a
command that does not get affected by the commit.cleanup variable,
and with such a bogus configuration, a command that does use the
variable should either also die, or fallback with a warning.
I have a suspicion that the change is breaking the error detection
done for the command line argument parsing, and if that is the case,
then it is a bad idea. But I may have misread the code.
Thanks.
