diff mbox series

[v6,3/3] am: throw an error when passing --empty option without value

Message ID e907a2b2faa1e3c5854504c23cc6e118c2125817.1637232636.git.gitgitgadget@gmail.com (mailing list archive)
State Superseded
Headers show
Series am: support --empty=(die|drop|keep) option to handle empty patches | expand

Commit Message

徐沛文 (Aleen) Nov. 18, 2021, 10:50 a.m. UTC
From: Aleen <aleen42@vip.qq.com>

Signed-off-by: Aleen <aleen42@vip.qq.com>
---
 builtin/am.c  | 13 +++++++------
 t/t4150-am.sh |  8 +++++++-
 2 files changed, 14 insertions(+), 7 deletions(-)

Comments

Junio C Hamano Nov. 19, 2021, 1:13 a.m. UTC | #1
"Aleen via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Aleen <aleen42@vip.qq.com>

Here is a place for you to explain why this change might be a good
idea to defend it.  If we applied 1/3 and 2/3 but not this one, what
happens?  "am --empty" (not "am --empty=<choice>") is accepted and
behaves just like "am --empty=die"?  Is that a bad thing?

If it is unconditonally a bad thing, then this patch does not stand
on its own.  It should be squashed into the previous step; otherwise
it would be "oops, we didn't think it through and failed to detect
an argument-less --error as an error in the previous step, and here
is a fix for that mistake".  We try not to deliberately commit a
mistake and then fix it to gain commit counts in this project (or
putting it differently, we try to pretend we are better than we
really are and did not make a mistake in the first place).

Or are you giving list participants and reviewers a choice between
"'--empty' is a synonym to '--empty=die'" and "'--empty' alone is an
error" because you cannot decide yourself?  If that is the case, you
really really need to make it clear in this place between "From:"
and "Signed-off-by:".  Why would we want to use this patch?  Why
would we be better without this patch?

I haven't thought things through, but my gut feeling is that the
semantics of the --empty=<choice> option is better _with_ this,
in other words, it makes more sense to forbid "--empty" alone.  So
if I were doing this series, I would probably have squashed this
into the previous one, making it a two-patch series.

Thanks.


> Signed-off-by: Aleen <aleen42@vip.qq.com>
> ---
>  builtin/am.c  | 13 +++++++------
>  t/t4150-am.sh |  8 +++++++-
>  2 files changed, 14 insertions(+), 7 deletions(-)


> diff --git a/builtin/am.c b/builtin/am.c
> index 1a3ed87b445..5d487b5256b 100644
> --- a/builtin/am.c
> +++ b/builtin/am.c
> @@ -185,12 +185,14 @@ static int am_option_parse_quoted_cr(const struct option *opt,
>  	return 0;
>  }
>  
> -static int am_option_parse_empty_commit(const struct option *opt,
> +static int am_option_parse_empty(const struct option *opt,
>  				     const char *arg, int unset)
>  {
>  	int *opt_value = opt->value;
>  
> -	if (unset || !strcmp(arg, "die"))
> +	BUG_ON_OPT_NEG(unset);



> +	if (!strcmp(arg, "die"))
>  		*opt_value = DIE_EMPTY_COMMIT;
>  	else if (!strcmp(arg, "drop"))
>  		*opt_value = DROP_EMPTY_COMMIT;
> @@ -2391,10 +2393,9 @@ int cmd_am(int argc, const char **argv, const char *prefix)
>  		{ OPTION_STRING, 'S', "gpg-sign", &state.sign_commit, N_("key-id"),
>  		  N_("GPG-sign commits"),
>  		  PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
> -		{ OPTION_CALLBACK, 0, "empty", &state.empty_type,
> -		  "(die|drop|keep)",
> -		  N_("specify how to handle empty patches"),
> -		  PARSE_OPT_OPTARG, am_option_parse_empty_commit },
> +		OPT_CALLBACK_F(0, "empty", &state.empty_type, "{drop,keep,die}",
> +		  N_("how to handle empty patches"),
> +		  PARSE_OPT_NONEG, am_option_parse_empty),
>  		OPT_HIDDEN_BOOL(0, "rebasing", &state.rebasing,
>  			N_("(internal use for git-rebase)")),
>  		OPT_END()
> diff --git a/t/t4150-am.sh b/t/t4150-am.sh
> index 3119556884d..c32d21e80da 100755
> --- a/t/t4150-am.sh
> +++ b/t/t4150-am.sh
> @@ -1165,8 +1165,14 @@ test_expect_success 'still output error with --empty when meeting empty files' '
>  	test_cmp expected actual
>  '
>  
> -test_expect_success 'error when meeting e-mail message that lacks a patch by default' '
> +test_expect_success 'invalid when passing no value for the --empty option' '
>  	git checkout empty-commit^ &&
> +	test_must_fail git am --empty empty-commit.patch 2>err &&
> +	echo "error: Invalid value for --empty: empty-commit.patch" >expected &&
> +	test_cmp expected err
> +'
> +
> +test_expect_success 'error when meeting e-mail message that lacks a patch by default' '
>  	test_must_fail git am empty-commit.patch >err &&
>  	test_path_is_dir .git/rebase-apply &&
>  	test_i18ngrep "Patch is empty." err &&
Aleen 徐沛文 Nov. 19, 2021, 2:11 a.m. UTC | #2
> Here is a place for you to explain why this change might be a good
> idea to defend it.  If we applied 1/3 and 2/3 but not this one, what
> happens?  "am --empty" (not "am --empty=<choice>") is accepted and
> behaves just like "am --empty=die"?  Is that a bad thing?
> 
> If it is unconditonally a bad thing, then this patch does not stand
> on its own.  It should be squashed into the previous step; otherwise
> it would be "oops, we didn't think it through and failed to detect
> an argument-less --error as an error in the previous step, and here
> is a fix for that mistake".  We try not to deliberately commit a
> mistake and then fix it to gain commit counts in this project (or
> putting it differently, we try to pretend we are better than we
> really are and did not make a mistake in the first place).
> 
> Or are you giving list participants and reviewers a choice between
> "'--empty' is a synonym to '--empty=die'" and "'--empty' alone is an
> error" because you cannot decide yourself?  If that is the case, you
> really really need to make it clear in this place between "From:"
> and "Signed-off-by:".  Why would we want to use this patch?  Why
> would we be better without this patch?
> 
> I haven't thought things through, but my gut feeling is that the
> semantics of the --empty=<choice> option is better _with_ this,
> in other words, it makes more sense to forbid "--empty" alone.  So
> if I were doing this series, I would probably have squashed this
> into the previous one, making it a two-patch series.
> 
> Thanks.

Hamano, I could not make this decision like what you said between "'--empty' is a synonym to '--empty=die'" and "'--empty' alone is an error". In my opinion, it is a little wired that '--empty' should not act as "died" semantically. Reversely, it may be better to support a synonym between '--quiet' and '--empty=skip'.

I will squash the commit into the previous one later and hope all participants and reviewers make a decision.
diff mbox series

Patch

diff --git a/builtin/am.c b/builtin/am.c
index 1a3ed87b445..5d487b5256b 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -185,12 +185,14 @@  static int am_option_parse_quoted_cr(const struct option *opt,
 	return 0;
 }
 
-static int am_option_parse_empty_commit(const struct option *opt,
+static int am_option_parse_empty(const struct option *opt,
 				     const char *arg, int unset)
 {
 	int *opt_value = opt->value;
 
-	if (unset || !strcmp(arg, "die"))
+	BUG_ON_OPT_NEG(unset);
+
+	if (!strcmp(arg, "die"))
 		*opt_value = DIE_EMPTY_COMMIT;
 	else if (!strcmp(arg, "drop"))
 		*opt_value = DROP_EMPTY_COMMIT;
@@ -2391,10 +2393,9 @@  int cmd_am(int argc, const char **argv, const char *prefix)
 		{ OPTION_STRING, 'S', "gpg-sign", &state.sign_commit, N_("key-id"),
 		  N_("GPG-sign commits"),
 		  PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
-		{ OPTION_CALLBACK, 0, "empty", &state.empty_type,
-		  "(die|drop|keep)",
-		  N_("specify how to handle empty patches"),
-		  PARSE_OPT_OPTARG, am_option_parse_empty_commit },
+		OPT_CALLBACK_F(0, "empty", &state.empty_type, "{drop,keep,die}",
+		  N_("how to handle empty patches"),
+		  PARSE_OPT_NONEG, am_option_parse_empty),
 		OPT_HIDDEN_BOOL(0, "rebasing", &state.rebasing,
 			N_("(internal use for git-rebase)")),
 		OPT_END()
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 3119556884d..c32d21e80da 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -1165,8 +1165,14 @@  test_expect_success 'still output error with --empty when meeting empty files' '
 	test_cmp expected actual
 '
 
-test_expect_success 'error when meeting e-mail message that lacks a patch by default' '
+test_expect_success 'invalid when passing no value for the --empty option' '
 	git checkout empty-commit^ &&
+	test_must_fail git am --empty empty-commit.patch 2>err &&
+	echo "error: Invalid value for --empty: empty-commit.patch" >expected &&
+	test_cmp expected err
+'
+
+test_expect_success 'error when meeting e-mail message that lacks a patch by default' '
 	test_must_fail git am empty-commit.patch >err &&
 	test_path_is_dir .git/rebase-apply &&
 	test_i18ngrep "Patch is empty." err &&