[PATCH] Remove deprecated OPTION_BOOLEAN

[PATCH] Remove deprecated OPTION_BOOLEAN

[Stefan Beller]

Hi,
the following patch removes the OPTION_BOOLEAN from 
all commands.

So recently Junio released -rc0. Is that a reason to not
send out patches, which do not do bugfixes? So the following 
commit for example doesn't fix a bug nor does it add a feature.
Is it fine to send out such kind of commits during the -rc
times or better wait for the next development cycle?

Stefan

Stefan Beller (1):
  Remove deprecated OPTION_BOOLEAN for parsing command line arguments

 builtin/checkout.c |  5 ++---
 builtin/clone.c    |  7 +++----
 builtin/commit.c   | 10 ++++------
 builtin/log.c      |  4 ++--
 builtin/notes.c    |  8 ++++----
 builtin/show-ref.c |  5 ++---
 parse-options.h    |  5 ++---
 7 files changed, 19 insertions(+), 25 deletions(-)

-- 
1.8.4.rc0.1.g8f6a3e5

[PATCH] Remove deprecated OPTION_BOOLEAN

[Stefan Beller]

As of b04ba2bb4 OPTION_BOOLEAN was deprecated.
This commit removes all occurrences of OPTION_BOOLEAN.
In b04ba2bb4 Junio suggested to replace it with either
OPTION_SET_INT or OPTION_COUNTUP instead. However a pattern, which
occurred often with the OPTION_BOOLEAN was a hidden boolean parameter.
So I defined OPT_HIDDEN_BOOL as an additional possible parse option
in parse-options.h to make life easy.

The OPT_HIDDEN_BOOL was used in checkout, clone, commit, show-ref.
The only exception, where there was need to fiddle with OPTION_SET_INT
was log and notes. However in these two files there is also a pattern,
so we could think of introducing OPT_NONEG_BOOL.

Signed-off-by: Stefan Beller <stefanbeller@googlemail.com>
---
 builtin/checkout.c |  5 ++---
 builtin/clone.c    |  7 +++----
 builtin/commit.c   | 10 ++++------
 builtin/log.c      |  4 ++--
 builtin/notes.c    |  8 ++++----
 builtin/show-ref.c |  5 ++---
 parse-options.h    |  5 ++---
 7 files changed, 19 insertions(+), 25 deletions(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index 7025938..646a475 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1073,9 +1073,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
 		OPT_BOOLEAN('p', "patch", &opts.patch_mode, N_("select hunks interactively")),
 		OPT_BOOL(0, "ignore-skip-worktree-bits", &opts.ignore_skipworktree,
 			 N_("do not limit pathspecs to sparse entries only")),
-		{ OPTION_BOOLEAN, 0, "guess", &dwim_new_local_branch, NULL,
-		  N_("second guess 'git checkout no-such-branch'"),
-		  PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },
+		OPT_HIDDEN_BOOL(0, "guess", &dwim_new_local_branch,
+				N_("second guess 'git checkout no-such-branch'")),
 		OPT_END(),
 	};
 
diff --git a/builtin/clone.c b/builtin/clone.c
index 430307b..e7b0b13 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -64,10 +64,9 @@ static struct option builtin_clone_options[] = {
 		 N_("force progress reporting")),
 	OPT_BOOLEAN('n', "no-checkout", &option_no_checkout,
 		    N_("don't create a checkout")),
-	OPT_BOOLEAN(0, "bare", &option_bare, N_("create a bare repository")),
-	{ OPTION_BOOLEAN, 0, "naked", &option_bare, NULL,
-		N_("create a bare repository"),
-		PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },
+	OPT_BOOL(0, "bare", &option_bare, N_("create a bare repository")),
+	OPT_HIDDEN_BOOL(0, "naked", &option_bare,
+			N_("create a bare repository")),
 	OPT_BOOLEAN(0, "mirror", &option_mirror,
 		    N_("create a mirror repository (implies bare)")),
 	OPT_BOOL('l', "local", &option_local,
diff --git a/builtin/commit.c b/builtin/commit.c
index 003bd7d..b64a083 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1448,12 +1448,10 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 		{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg, N_("mode"), N_("show untracked files, optional modes: all, normal, no. (Default: all)"), PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
 		/* end commit contents options */
 
-		{ OPTION_BOOLEAN, 0, "allow-empty", &allow_empty, NULL,
-		  N_("ok to record an empty change"),
-		  PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },
-		{ OPTION_BOOLEAN, 0, "allow-empty-message", &allow_empty_message, NULL,
-		  N_("ok to record a change with an empty message"),
-		  PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },
+		OPT_HIDDEN_BOOL(0, "allow-empty", &allow_empty,
+				N_("ok to record an empty change")),
+		OPT_HIDDEN_BOOL(0, "allow-empty-message", &allow_empty_message,
+				N_("ok to record a change with an empty message")),
 
 		OPT_END()
 	};
diff --git a/builtin/log.c b/builtin/log.c
index 2625f98..05e374d 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1183,9 +1183,9 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 			    N_("don't output binary diffs")),
 		OPT_BOOLEAN(0, "ignore-if-in-upstream", &ignore_if_in_upstream,
 			    N_("don't include a patch matching a commit upstream")),
-		{ OPTION_BOOLEAN, 'p', "no-stat", &use_patch_format, NULL,
+		{ OPTION_SET_INT, 'p', "no-stat", &use_patch_format, NULL,
 		  N_("show patch format instead of default (patch + stat)"),
-		  PARSE_OPT_NONEG | PARSE_OPT_NOARG },
+		  PARSE_OPT_NONEG | PARSE_OPT_NOARG, NULL, 1},
 		OPT_GROUP(N_("Messaging")),
 		{ OPTION_CALLBACK, 0, "add-header", NULL, N_("header"),
 			    N_("add email header"), 0, header_callback },
diff --git a/builtin/notes.c b/builtin/notes.c
index e4100c4..8f63cb2 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -739,13 +739,13 @@ static int merge(int argc, const char **argv, const char *prefix)
 			   N_("resolve notes conflicts using the given strategy "
 			      "(manual/ours/theirs/union/cat_sort_uniq)")),
 		OPT_GROUP(N_("Committing unmerged notes")),
-		{ OPTION_BOOLEAN, 0, "commit", &do_commit, NULL,
+		{ OPTION_SET_INT, 0, "commit", &do_commit, NULL,
 			N_("finalize notes merge by committing unmerged notes"),
-			PARSE_OPT_NOARG | PARSE_OPT_NONEG },
+			PARSE_OPT_NOARG | PARSE_OPT_NONEG, NULL, 1},
 		OPT_GROUP(N_("Aborting notes merge resolution")),
-		{ OPTION_BOOLEAN, 0, "abort", &do_abort, NULL,
+		{ OPTION_SET_INT, 0, "abort", &do_abort, NULL,
 			N_("abort notes merge"),
-			PARSE_OPT_NOARG | PARSE_OPT_NONEG },
+			PARSE_OPT_NOARG | PARSE_OPT_NONEG, NULL, 1},
 		OPT_END()
 	};
 
diff --git a/builtin/show-ref.c b/builtin/show-ref.c
index 87806ad..18680bb 100644
--- a/builtin/show-ref.c
+++ b/builtin/show-ref.c
@@ -169,9 +169,8 @@ static const struct option show_ref_options[] = {
 	OPT_BOOLEAN(0, "heads", &heads_only, N_("only show heads (can be combined with tags)")),
 	OPT_BOOLEAN(0, "verify", &verify, N_("stricter reference checking, "
 		    "requires exact ref path")),
-	{ OPTION_BOOLEAN, 'h', NULL, &show_head, NULL,
-	  N_("show the HEAD reference, even if it would be filtered out"),
-	  PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },
+	OPT_HIDDEN_BOOL('h', NULL, &show_head,
+			N_("show the HEAD reference, even if it would be filtered out")),
 	OPT_BOOLEAN(0, "head", &show_head,
 	  N_("show the HEAD reference, even if it would be filtered out")),
 	OPT_BOOLEAN('d', "dereference", &deref_tags,
diff --git a/parse-options.h b/parse-options.h
index c378b75..db6a6fe 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -21,9 +21,6 @@ enum parse_opt_type {
 	OPTION_FILENAME
 };
 
-/* Deprecated synonym */
-#define OPTION_BOOLEAN OPTION_COUNTUP
-
 enum parse_opt_flags {
 	PARSE_OPT_KEEP_DASHDASH = 1,
 	PARSE_OPT_STOP_AT_NON_OPTION = 2,
@@ -128,6 +125,8 @@ struct option {
 #define OPT_SET_INT(s, l, v, h, i)  { OPTION_SET_INT, (s), (l), (v), NULL, \
 				      (h), PARSE_OPT_NOARG, NULL, (i) }
 #define OPT_BOOL(s, l, v, h)        OPT_SET_INT(s, l, v, h, 1)
+#define OPT_HIDDEN_BOOL(s, l, v, h) { OPTION_SET_INT, (s), (l), (v), NULL, \
+				      (h), PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, 1}
 #define OPT_SET_PTR(s, l, v, h, p)  { OPTION_SET_PTR, (s), (l), (v), NULL, \
 				      (h), PARSE_OPT_NOARG, NULL, (p) }
 #define OPT_INTEGER(s, l, v, h)     { OPTION_INTEGER, (s), (l), (v), N_("n"), (h) }
-- 
1.8.4.rc0.1.g8f6a3e5

Re: [PATCH] Remove deprecated OPTION_BOOLEAN

[Junio C Hamano]

Stefan Beller <stefanbeller@googlemail.com> writes:

> So recently Junio released -rc0. Is that a reason to not
> send out patches, which do not do bugfixes? So the following 
> commit for example doesn't fix a bug nor does it add a feature.
> Is it fine to send out such kind of commits during the -rc
> times or better wait for the next development cycle?

It would be a good idea to show it to others as a preview of what to
come even in a pre-release freeze period, so that people holding
real patches in the affected area can work with you to avoid
conflicts.

But I would not expect them to be applied to the upcoming release,
nor even 'next'---this largely depends on the maintainer workload.

Thanks.

Re: [PATCH] Remove deprecated OPTION_BOOLEAN

[Stefan Beller]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

On 07/29/2013 07:58 PM, Junio C Hamano wrote:
> Stefan Beller <stefanbeller@googlemail.com> writes:
> 
>> So recently Junio released -rc0. Is that a reason to not
>> send out patches, which do not do bugfixes? So the following 
>> commit for example doesn't fix a bug nor does it add a feature.
>> Is it fine to send out such kind of commits during the -rc
>> times or better wait for the next development cycle?
> 
> It would be a good idea to show it to others as a preview of what to
> come even in a pre-release freeze period, so that people holding
> real patches in the affected area can work with you to avoid
> conflicts.
> 
> But I would not expect them to be applied to the upcoming release,
> nor even 'next'---this largely depends on the maintainer workload.
> 
> Thanks.
> 

Thanks for the answer. Let me rephrase the question a little bit:
Would you rather encourage to send it out now, or later?
("I'll apply it ot a local branch and eventually remember it next
release to merge." or "I'll forget about such stuff, you need to
resend it anyway.")

Regarding possible merge conflicts I'd be happy to resolve them
and not add a burden to people doing features.

Stefan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [PATCH] Remove deprecated OPTION_BOOLEAN

[Junio C Hamano]

Stefan Beller <stefanbeller@googlemail.com> writes:

> As of b04ba2bb4 OPTION_BOOLEAN was deprecated.

The primary purpose of b04ba2bb (parse-options: deprecate
OPT_BOOLEAN, 2011-09-27) is to deprecate OPT_BOOLEAN(), which was
hard to use correctly.

OPT_BOOLEAN() is not touched at all with this patch, it seems.  Do
they want count-up semantics?

> This commit removes all occurrences of OPTION_BOOLEAN.
> In b04ba2bb4 Junio suggested to replace it with either
> OPTION_SET_INT or OPTION_COUNTUP instead. However a pattern, which
> occurred often with the OPTION_BOOLEAN was a hidden boolean parameter.
> So I defined OPT_HIDDEN_BOOL as an additional possible parse option
> in parse-options.h to make life easy.
>
> The OPT_HIDDEN_BOOL was used in checkout, clone, commit, show-ref.
> The only exception, where there was need to fiddle with OPTION_SET_INT
> was log and notes. However in these two files there is also a pattern,
> so we could think of introducing OPT_NONEG_BOOL.
>
> Signed-off-by: Stefan Beller <stefanbeller@googlemail.com>

At first glance, it looked to me that OPT_HIDDEN_BOOL was a good
addition, given how often we have PARSE_OPT_HIDDEN.  While I think
some of the hidden ones are justified, I am not sure if the hiding
of many options are.  If we stop hiding many of them, HIDDEN_BOOL
may become not so useful.  I dunno.

Re: [PATCH] Remove deprecated OPTION_BOOLEAN

[Stefan Beller]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

On 07/29/2013 08:11 PM, Junio C Hamano wrote:
> Stefan Beller <stefanbeller@googlemail.com> writes:
> 
>> As of b04ba2bb4 OPTION_BOOLEAN was deprecated.
> 
> The primary purpose of b04ba2bb (parse-options: deprecate
> OPT_BOOLEAN, 2011-09-27) is to deprecate OPT_BOOLEAN(), which was
> hard to use correctly.
> 
> OPT_BOOLEAN() is not touched at all with this patch, it seems.  Do
> they want count-up semantics?
> 

I'm working on the OPT_BOOLEAN replacement as well, but the 
OPTION_BOOLEAN seemed as an easier start (way less until completion)

> At first glance, it looked to me that OPT_HIDDEN_BOOL was a good
> addition, given how often we have PARSE_OPT_HIDDEN.  While I think
> some of the hidden ones are justified, I am not sure if the hiding
> of many options are.  If we stop hiding many of them, HIDDEN_BOOL
> may become not so useful.  I dunno.

There should be no change in semantics.
All those which now use the OPT_HIDDEN_BOOL have had 
{OPTION_BOOLEAN,..., PARSE_OPT_HIDDEN}
before.

But your concern sounds more like you'd dislike the
appearance of OPT_HIDDEN_BOOL because you'd want to remove the
hidden options. The options being hidden there sound to me as if
those were hidden due to their historical nature and there is always
a non-hidden equivalent being better worded.

Stefan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [PATCH] Remove deprecated OPTION_BOOLEAN

[Junio C Hamano]

Stefan Beller <stefanbeller@googlemail.com> writes:

> On 07/29/2013 07:58 PM, Junio C Hamano wrote:
>> Stefan Beller <stefanbeller@googlemail.com> writes:
>> 
>>> So recently Junio released -rc0. Is that a reason to not
>>> send out patches, which do not do bugfixes? So the following 
>>> commit for example doesn't fix a bug nor does it add a feature.
>>> Is it fine to send out such kind of commits during the -rc
>>> times or better wait for the next development cycle?
>> 
>> It would be a good idea to show it to others as a preview of what to
>> come even in a pre-release freeze period, so that people holding
>> real patches in the affected area can work with you to avoid
>> conflicts.
>> 
>> But I would not expect them to be applied to the upcoming release,
>> nor even 'next'---this largely depends on the maintainer workload.
>> 
>> Thanks.
>> 
>
> Thanks for the answer. Let me rephrase the question a little bit:
> Would you rather encourage to send it out now, or later?
> ("I'll apply it ot a local branch and eventually remember it next
> release to merge." or "I'll forget about such stuff, you need to
> resend it anyway.")

It is closer to the latter ("I'd appreciate if submitters let me
forget about them"), but still you may want to send them out for
early reviews from others.

>
> Regarding possible merge conflicts I'd be happy to resolve them
> and not add a burden to people doing features.
>
> Stefan