[PATCH 0/3] Add some more options to the pretty-formats

[PATCH 0/3] Add some more options to the pretty-formats

[Eli Schwartz]

While discussing adding git archive support to a software versioning
tool, the issue came up that apparently many people (maybe in the python
community specifically?) use lightweight tags for releases.

While it would be nice if the current describe functionality for
export-subst was sufficient to cover the average reasonable use, this is
apparently not the case; at least --tags support will most likely need
to be added. The alternative is documenting a workflow change and having
the versioning tool raise some kind of error if you use the wrong kind
of tag, which is not an exciting requirement for the project maintainer.

In my initial proposal of the %(describe) feature I gave an example
using --tags, but it never ended up in the initial implementation:

https://public-inbox.org/git/7418f1d8-78c2-61a7-4f03-62360b986a41@archlinux.org/

So I figured I'd take a stab at it myself. While I was at it, I looked
at the options available to git describe and came up with a use case for
adding --abbrev support too.

Eli Schwartz (3):
  pretty.c: rename describe options variable to more descriptive name
  pretty: add tag option to %(describe)
  pretty: add abbrev option to %(describe)

 Documentation/pretty-formats.txt | 15 ++++++++++-----
 pretty.c                         | 31 +++++++++++++++++++++++--------
 t/t4205-log-pretty-formats.sh    | 16 ++++++++++++++++
 3 files changed, 49 insertions(+), 13 deletions(-)

-- 
2.33.1

[PATCH 1/3] pretty.c: rename describe options variable to more descriptive name

[Eli Schwartz]

It contains option arguments, not options. We would like to add option
support here too.

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
---
 pretty.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/pretty.c b/pretty.c
index 73b5ead509..9db2c65538 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1216,7 +1216,7 @@ int format_set_trailers_options(struct process_trailer_options *opts,
 
 static size_t parse_describe_args(const char *start, struct strvec *args)
 {
-	const char *options[] = { "match", "exclude" };
+	const char *option_arguments[] = { "match", "exclude" };
 	const char *arg = start;
 
 	for (;;) {
@@ -1225,10 +1225,10 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 		size_t arglen = 0;
 		int i;
 
-		for (i = 0; i < ARRAY_SIZE(options); i++) {
-			if (match_placeholder_arg_value(arg, options[i], &arg,
+		for (i = 0; i < ARRAY_SIZE(option_arguments); i++) {
+			if (match_placeholder_arg_value(arg, option_arguments[i], &arg,
 							&argval, &arglen)) {
-				matched = options[i];
+				matched = option_arguments[i];
 				break;
 			}
 		}
-- 
2.33.1

Re: [PATCH 1/3] pretty.c: rename describe options variable to more descriptive name

[Junio C Hamano]

Eli Schwartz <eschwartz@archlinux.org> writes:

> It contains option arguments, not options. We would like to add option
> support here too.
>
> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
> ---
>  pretty.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/pretty.c b/pretty.c
> index 73b5ead509..9db2c65538 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -1216,7 +1216,7 @@ int format_set_trailers_options(struct process_trailer_options *opts,
>  
>  static size_t parse_describe_args(const char *start, struct strvec *args)
>  {
> -	const char *options[] = { "match", "exclude" };
> +	const char *option_arguments[] = { "match", "exclude" };

This renaming is more or less "Meh" without the other change in the
series that may (or may not) be helped with this step, but because I
haven't seen these later steps yet, I may sound too dismissive of
the change in this step.

Anyway, at least call that option_args[] to match the way the
function calls itself, not option_arguments[] that is a mouthful for
a mere implementation detail of local variable for a file-private
helper function.

Thanks.

>  	const char *arg = start;
>  
>  	for (;;) {
> @@ -1225,10 +1225,10 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
>  		size_t arglen = 0;
>  		int i;
>  
> -		for (i = 0; i < ARRAY_SIZE(options); i++) {
> -			if (match_placeholder_arg_value(arg, options[i], &arg,
> +		for (i = 0; i < ARRAY_SIZE(option_arguments); i++) {
> +			if (match_placeholder_arg_value(arg, option_arguments[i], &arg,
>  							&argval, &arglen)) {
> -				matched = options[i];
> +				matched = option_arguments[i];
>  				break;
>  			}
>  		}

Re: [PATCH 1/3] pretty.c: rename describe options variable to more descriptive name

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1471 bytes --]

On 10/24/21 12:31 AM, Junio C Hamano wrote:
> Eli Schwartz <eschwartz@archlinux.org> writes:
> 
>> It contains option arguments, not options. We would like to add option
>> support here too.
>>
>> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
>> ---
>>  pretty.c | 8 ++++----
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/pretty.c b/pretty.c
>> index 73b5ead509..9db2c65538 100644
>> --- a/pretty.c
>> +++ b/pretty.c
>> @@ -1216,7 +1216,7 @@ int format_set_trailers_options(struct process_trailer_options *opts,
>>  
>>  static size_t parse_describe_args(const char *start, struct strvec *args)
>>  {
>> -	const char *options[] = { "match", "exclude" };
>> +	const char *option_arguments[] = { "match", "exclude" };
> 
> This renaming is more or less "Meh" without the other change in the
> series that may (or may not) be helped with this step, but because I
> haven't seen these later steps yet, I may sound too dismissive of
> the change in this step.
> 
> Anyway, at least call that option_args[] to match the way the
> function calls itself, not option_arguments[] that is a mouthful for
> a mere implementation detail of local variable for a file-private
> helper function.


Right, the reason this change was submitted in its own patch was
essentially for the sole purpose of making the diff for the second patch
intuitive to read.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

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

[PATCH 2/3] pretty: add tag option to %(describe)

[Eli Schwartz]

The %(describe) placeholder by default, like `git describe`, only
supports annotated tags. However, some people do use lightweight tags
for releases, and would like to describe those anyway. The command line
tool has an option to support this.

Teach the placeholder to support this as well.

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
---
 Documentation/pretty-formats.txt | 11 ++++++-----
 pretty.c                         | 23 +++++++++++++++++++----
 t/t4205-log-pretty-formats.sh    |  8 ++++++++
 3 files changed, 33 insertions(+), 9 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index ef6bd420ae..14107ac191 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -220,6 +220,7 @@ The placeholders are:
 			  inconsistent when tags are added or removed at
 			  the same time.
 +
+** 'tags[=<BOOL>]': Also consider lightweight tags.
 ** 'match=<pattern>': Only consider tags matching the given
    `glob(7)` pattern, excluding the "refs/tags/" prefix.
 ** 'exclude=<pattern>': Do not consider tags matching the given
@@ -273,11 +274,6 @@ endif::git-rev-list[]
 			  If any option is provided multiple times the
 			  last occurrence wins.
 +
-The boolean options accept an optional value `[=<BOOL>]`. The values
-`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
-sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
-option is given with no value, it's enabled.
-+
 ** 'key=<K>': only show trailers with specified key. Matching is done
    case-insensitively and trailing colon is optional. If option is
    given multiple times trailer lines matching any of the keys are
@@ -313,6 +309,11 @@ insert an empty string unless we are traversing reflog entries (e.g., by
 decoration format if `--decorate` was not already provided on the command
 line.
 
+The boolean options accept an optional value `[=<BOOL>]`. The values
+`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
+sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
+option is given with no value, it's enabled.
+
 If you add a `+` (plus sign) after '%' of a placeholder, a line-feed
 is inserted immediately before the expansion if and only if the
 placeholder expands to a non-empty string.
diff --git a/pretty.c b/pretty.c
index 9db2c65538..3a41bedf1a 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1216,28 +1216,43 @@ int format_set_trailers_options(struct process_trailer_options *opts,
 
 static size_t parse_describe_args(const char *start, struct strvec *args)
 {
+	const char *options[] = { "tags" };
 	const char *option_arguments[] = { "match", "exclude" };
 	const char *arg = start;
 
 	for (;;) {
 		const char *matched = NULL;
-		const char *argval;
+		const char *argval = NULL;
 		size_t arglen = 0;
+		int optval = 0;
 		int i;
 
 		for (i = 0; i < ARRAY_SIZE(option_arguments); i++) {
 			if (match_placeholder_arg_value(arg, option_arguments[i], &arg,
 							&argval, &arglen)) {
 				matched = option_arguments[i];
+				if (!arglen)
+					return 0;
 				break;
 			}
 		}
+		if (!matched)
+			for (i = 0; i < ARRAY_SIZE(options); i++) {
+				if (match_placeholder_bool_arg(arg, options[i], &arg,
+								&optval)) {
+					matched = options[i];
+					break;
+				}
+			}
 		if (!matched)
 			break;
 
-		if (!arglen)
-			return 0;
-		strvec_pushf(args, "--%s=%.*s", matched, (int)arglen, argval);
+
+		if (argval) {
+			strvec_pushf(args, "--%s=%.*s", matched, (int)arglen, argval);
+		} else if (optval) {
+			strvec_pushf(args, "--%s", matched);
+		}
 	}
 	return arg - start;
 }
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 5865daa8f8..d4acf8882f 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -1002,4 +1002,12 @@ test_expect_success '%(describe:exclude=...) vs git describe --exclude ...' '
 	test_cmp expect actual
 '
 
+test_expect_success '%(describe:tags) vs git describe --tags' '
+	test_when_finished "git tag -d tagname" &&
+	git tag tagname &&
+	git describe --tags >expect &&
+	git log -1 --format="%(describe:tags)" >actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.33.1

Re: [PATCH 2/3] pretty: add tag option to %(describe)

[Junio C Hamano]

Eli Schwartz <eschwartz@archlinux.org> writes:

> The %(describe) placeholder by default, like `git describe`, only
> supports annotated tags. However, some people do use lightweight tags
> for releases, and would like to describe those anyway. The command line
> tool has an option to support this.
>
> Teach the placeholder to support this as well.
>
> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
> ---
>  Documentation/pretty-formats.txt | 11 ++++++-----
>  pretty.c                         | 23 +++++++++++++++++++----
>  t/t4205-log-pretty-formats.sh    |  8 ++++++++
>  3 files changed, 33 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> index ef6bd420ae..14107ac191 100644
> --- a/Documentation/pretty-formats.txt
> +++ b/Documentation/pretty-formats.txt
> @@ -220,6 +220,7 @@ The placeholders are:
>  			  inconsistent when tags are added or removed at
>  			  the same time.
>  +
> +** 'tags[=<BOOL>]': Also consider lightweight tags.
>  ** 'match=<pattern>': Only consider tags matching the given
>     `glob(7)` pattern, excluding the "refs/tags/" prefix.
>  ** 'exclude=<pattern>': Do not consider tags matching the given

What is the guiding principle used in this patch to decide where the
new entry should go?  

The existing 'match' and 'exclude' are the opposites to each other,
and it makes sense to keep them together, and between them, 'match'
is the positive variant while 'exclude' is the negative one, so the
current order makes sense.  I wonder why the new "also consider"
should come before them, instead of after.

I am not saying you should change the order, and I would be most
unhappy if you did so without explanation in an updated patch.
Rather, I would like to hear the reasoning behind the decision,
preferrably in the proposed log message.

> @@ -273,11 +274,6 @@ endif::git-rev-list[]
>  			  If any option is provided multiple times the
>  			  last occurrence wins.
>  +
> -The boolean options accept an optional value `[=<BOOL>]`. The values
> -`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
> -sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
> -option is given with no value, it's enabled.
> -+
>  ** 'key=<K>': only show trailers with specified key. Matching is done
>     case-insensitively and trailing colon is optional. If option is
>     given multiple times trailer lines matching any of the keys are
> @@ -313,6 +309,11 @@ insert an empty string unless we are traversing reflog entries (e.g., by
>  decoration format if `--decorate` was not already provided on the command
>  line.
>  
> +The boolean options accept an optional value `[=<BOOL>]`. The values
> +`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
> +sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
> +option is given with no value, it's enabled.
> +

This paragraph used to be inside the description of %(trailers:...),
but that was only because %(trailers) was the only one that took a
boolean value for its options, and not because it was the only one
that had special treatment for its boolean options.  Because the
existing rule for an option that takes a boolean value equally
applies to the %(describe:...), and more importantly, because we
expect that any other pretty-format placeholder that would acquire
an option with boolean value would follow the same rule, it makes
sense to move it here, together with other rules like %+ and %- that
apply to any placeholders.

Makes sense.  I very much appreciate this extra attention to the
detail.


> diff --git a/pretty.c b/pretty.c
> index 9db2c65538..3a41bedf1a 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -1216,28 +1216,43 @@ int format_set_trailers_options(struct process_trailer_options *opts,
>  
>  static size_t parse_describe_args(const char *start, struct strvec *args)
>  {
> +	const char *options[] = { "tags" };
>  	const char *option_arguments[] = { "match", "exclude" };
>  	const char *arg = start;
>  
>  	for (;;) {
>  		const char *matched = NULL;
> -		const char *argval;
> +		const char *argval = NULL;
>  		size_t arglen = 0;
> +		int optval = 0;
>  		int i;
>  
>  		for (i = 0; i < ARRAY_SIZE(option_arguments); i++) {
>  			if (match_placeholder_arg_value(arg, option_arguments[i], &arg,
>  							&argval, &arglen)) {
>  				matched = option_arguments[i];
> +				if (!arglen)
> +					return 0;
>  				break;
>  			}
>  		}
> +		if (!matched)
> +			for (i = 0; i < ARRAY_SIZE(options); i++) {
> +				if (match_placeholder_bool_arg(arg, options[i], &arg,
> +								&optval)) {
> +					matched = options[i];
> +					break;
> +				}
> +			}
>  		if (!matched)
>  			break;
>  

I find this new structure of the code somewhat dubious.  Shouldn't
we be rather starting with an array of struct that describes the
token to match and how the token should be handled?  Something like

    struct {
	const char *name;
	enum { OPT_STRING, OPT_BOOL } type;
    } option[] = {
	{ "exclude", OPT_STRING },
        { "match", OPT_STRING },
	{ "tags", OPT_BOOL },
    };

    for (;;) {
	int i;
	int found = 0;
	...
        for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
            switch (option.type) {
            case OPT_STRING:
                if (match_placeholder_arg_value(...)) {
                    strvec_pushf(args, "--%s=%.*s", ...);
		    found = 1;
		}
                break;
            case OPT_BOOL:
                if (match_placeholder_bool_arg(...)) {
		    found = 1;
		    if (optval)
			strvec_pushf(args, "--%s", option.name);
		    else
			strvec_pushf(args, "--no-%s", option.name);
		}
		break;
	    }
	}
    }

And instead of the option -> option_arguments rename, the 1/3 of the
series can be to introduce the above structure, without introducing
OPT_BOOL and "tags" element to the option[] array.

> -		if (!arglen)
> -			return 0;
> -		strvec_pushf(args, "--%s=%.*s", matched, (int)arglen, argval);
> +
> +		if (argval) {
> +			strvec_pushf(args, "--%s=%.*s", matched, (int)arglen, argval);
> +		} else if (optval) {
> +			strvec_pushf(args, "--%s", matched);
> +		}
>  	}
>  	return arg - start;
>  }
> diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
> index 5865daa8f8..d4acf8882f 100755
> --- a/t/t4205-log-pretty-formats.sh
> +++ b/t/t4205-log-pretty-formats.sh
> @@ -1002,4 +1002,12 @@ test_expect_success '%(describe:exclude=...) vs git describe --exclude ...' '
>  	test_cmp expect actual
>  '
>  
> +test_expect_success '%(describe:tags) vs git describe --tags' '
> +	test_when_finished "git tag -d tagname" &&
> +	git tag tagname &&
> +	git describe --tags >expect &&
> +	git log -1 --format="%(describe:tags)" >actual &&
> +	test_cmp expect actual
> +'

Nice.

I like how the end-user visible part of this addition is designed to
look very much.  With a cleaned up implementation it would be great.

Thanks.

Re: [PATCH 2/3] pretty: add tag option to %(describe)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 8118 bytes --]

On 10/24/21 12:57 AM, Junio C Hamano wrote:
> Eli Schwartz <eschwartz@archlinux.org> writes:
> 
>> The %(describe) placeholder by default, like `git describe`, only
>> supports annotated tags. However, some people do use lightweight tags
>> for releases, and would like to describe those anyway. The command line
>> tool has an option to support this.
>>
>> Teach the placeholder to support this as well.
>>
>> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
>> ---
>>  Documentation/pretty-formats.txt | 11 ++++++-----
>>  pretty.c                         | 23 +++++++++++++++++++----
>>  t/t4205-log-pretty-formats.sh    |  8 ++++++++
>>  3 files changed, 33 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
>> index ef6bd420ae..14107ac191 100644
>> --- a/Documentation/pretty-formats.txt
>> +++ b/Documentation/pretty-formats.txt
>> @@ -220,6 +220,7 @@ The placeholders are:
>>  			  inconsistent when tags are added or removed at
>>  			  the same time.
>>  +
>> +** 'tags[=<BOOL>]': Also consider lightweight tags.
>>  ** 'match=<pattern>': Only consider tags matching the given
>>     `glob(7)` pattern, excluding the "refs/tags/" prefix.
>>  ** 'exclude=<pattern>': Do not consider tags matching the given
> 
> What is the guiding principle used in this patch to decide where the
> new entry should go?  
> 
> The existing 'match' and 'exclude' are the opposites to each other,
> and it makes sense to keep them together, and between them, 'match'
> is the positive variant while 'exclude' is the negative one, so the
> current order makes sense.  I wonder why the new "also consider"
> should come before them, instead of after.
> 
> I am not saying you should change the order, and I would be most
> unhappy if you did so without explanation in an updated patch.
> Rather, I would like to hear the reasoning behind the decision,
> preferrably in the proposed log message.


The guiding principle I used was to replicate the order in which the
same options are listed in git-describe(1).

Err, maybe that means I should not have used the word "also" in the doc
string...


>> @@ -273,11 +274,6 @@ endif::git-rev-list[]
>>  			  If any option is provided multiple times the
>>  			  last occurrence wins.
>>  +
>> -The boolean options accept an optional value `[=<BOOL>]`. The values
>> -`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
>> -sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
>> -option is given with no value, it's enabled.
>> -+
>>  ** 'key=<K>': only show trailers with specified key. Matching is done
>>     case-insensitively and trailing colon is optional. If option is
>>     given multiple times trailer lines matching any of the keys are
>> @@ -313,6 +309,11 @@ insert an empty string unless we are traversing reflog entries (e.g., by
>>  decoration format if `--decorate` was not already provided on the command
>>  line.
>>  
>> +The boolean options accept an optional value `[=<BOOL>]`. The values
>> +`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
>> +sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
>> +option is given with no value, it's enabled.
>> +
> 
> This paragraph used to be inside the description of %(trailers:...),
> but that was only because %(trailers) was the only one that took a
> boolean value for its options, and not because it was the only one
> that had special treatment for its boolean options.  Because the
> existing rule for an option that takes a boolean value equally
> applies to the %(describe:...), and more importantly, because we
> expect that any other pretty-format placeholder that would acquire
> an option with boolean value would follow the same rule, it makes
> sense to move it here, together with other rules like %+ and %- that
> apply to any placeholders.
> 
> Makes sense.  I very much appreciate this extra attention to the
> detail.


:)


>> diff --git a/pretty.c b/pretty.c
>> index 9db2c65538..3a41bedf1a 100644
>> --- a/pretty.c
>> +++ b/pretty.c
>> @@ -1216,28 +1216,43 @@ int format_set_trailers_options(struct process_trailer_options *opts,
>>  
>>  static size_t parse_describe_args(const char *start, struct strvec *args)
>>  {
>> +	const char *options[] = { "tags" };
>>  	const char *option_arguments[] = { "match", "exclude" };
>>  	const char *arg = start;
>>  
>>  	for (;;) {
>>  		const char *matched = NULL;
>> -		const char *argval;
>> +		const char *argval = NULL;
>>  		size_t arglen = 0;
>> +		int optval = 0;
>>  		int i;
>>  
>>  		for (i = 0; i < ARRAY_SIZE(option_arguments); i++) {
>>  			if (match_placeholder_arg_value(arg, option_arguments[i], &arg,
>>  							&argval, &arglen)) {
>>  				matched = option_arguments[i];
>> +				if (!arglen)
>> +					return 0;
>>  				break;
>>  			}
>>  		}
>> +		if (!matched)
>> +			for (i = 0; i < ARRAY_SIZE(options); i++) {
>> +				if (match_placeholder_bool_arg(arg, options[i], &arg,
>> +								&optval)) {
>> +					matched = options[i];
>> +					break;
>> +				}
>> +			}
>>  		if (!matched)
>>  			break;
>>  
> 
> I find this new structure of the code somewhat dubious.  Shouldn't
> we be rather starting with an array of struct that describes the
> token to match and how the token should be handled?  Something like
> 
>     struct {
> 	const char *name;
> 	enum { OPT_STRING, OPT_BOOL } type;
>     } option[] = {
> 	{ "exclude", OPT_STRING },
>         { "match", OPT_STRING },
> 	{ "tags", OPT_BOOL },
>     };
> 
>     for (;;) {
> 	int i;
> 	int found = 0;
> 	...
>         for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
>             switch (option.type) {
>             case OPT_STRING:
>                 if (match_placeholder_arg_value(...)) {
>                     strvec_pushf(args, "--%s=%.*s", ...);
> 		    found = 1;
> 		}
>                 break;
>             case OPT_BOOL:
>                 if (match_placeholder_bool_arg(...)) {
> 		    found = 1;
> 		    if (optval)
> 			strvec_pushf(args, "--%s", option.name);
> 		    else
> 			strvec_pushf(args, "--no-%s", option.name);
> 		}
> 		break;
> 	    }
> 	}
>     }
> 
> And instead of the option -> option_arguments rename, the 1/3 of the
> series can be to introduce the above structure, without introducing
> OPT_BOOL and "tags" element to the option[] array.


Maybe!

I'll confess that I'm a bit of a monkey-see-monkey-do coder when it
comes to C (I keep meaning to learn it properly, but as things stand I'm
a lot more comfortable in e.g. python). So there is a good chance I
could be a lot more optimized in my approach... your suggestion
resembles the kind of thing I might do in a language I know better.

I'll look into this, it makes sense.


>> -		if (!arglen)
>> -			return 0;
>> -		strvec_pushf(args, "--%s=%.*s", matched, (int)arglen, argval);
>> +
>> +		if (argval) {
>> +			strvec_pushf(args, "--%s=%.*s", matched, (int)arglen, argval);
>> +		} else if (optval) {
>> +			strvec_pushf(args, "--%s", matched);
>> +		}
>>  	}
>>  	return arg - start;
>>  }
>> diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
>> index 5865daa8f8..d4acf8882f 100755
>> --- a/t/t4205-log-pretty-formats.sh
>> +++ b/t/t4205-log-pretty-formats.sh
>> @@ -1002,4 +1002,12 @@ test_expect_success '%(describe:exclude=...) vs git describe --exclude ...' '
>>  	test_cmp expect actual
>>  '
>>  
>> +test_expect_success '%(describe:tags) vs git describe --tags' '
>> +	test_when_finished "git tag -d tagname" &&
>> +	git tag tagname &&
>> +	git describe --tags >expect &&
>> +	git log -1 --format="%(describe:tags)" >actual &&
>> +	test_cmp expect actual
>> +'
> 
> Nice.
> 
> I like how the end-user visible part of this addition is designed to
> look very much.  With a cleaned up implementation it would be great.
> 
> Thanks.
> 


-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

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

[PATCH 3/3] pretty: add abbrev option to %(describe)

[Eli Schwartz]

The %(describe) placeholder by default, like `git describe`, uses a
seven-character abbreviated commit hash. This may not be sufficient to
fully describe all git repos, resulting in a placeholder replacement
changing its length because the repository grew in size. This could
cause the output of git-archive to change.

Add the --abbrev option to `git describe` to the placeholder interface
in order to provide tools to the user for fine-tuning project defaults
and ensure reproducible archives.

One alternative would be to just always specify --abbrev=40 but this may
be a bit too biased...

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
---
 Documentation/pretty-formats.txt | 4 ++++
 pretty.c                         | 2 +-
 t/t4205-log-pretty-formats.sh    | 8 ++++++++
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 14107ac191..317c1382b5 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -221,6 +221,10 @@ The placeholders are:
 			  the same time.
 +
 ** 'tags[=<BOOL>]': Also consider lightweight tags.
+** 'abbrev=<N>': Instead of using the default number of hexadecimal digits
+   (which will vary according to the number of objects in the repository with a
+   default of 7) of the abbreviated object name, use <n> digits, or as many digits
+   as needed to form a unique object name.
 ** 'match=<pattern>': Only consider tags matching the given
    `glob(7)` pattern, excluding the "refs/tags/" prefix.
 ** 'exclude=<pattern>': Do not consider tags matching the given
diff --git a/pretty.c b/pretty.c
index 3a41bedf1a..a092457274 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1217,7 +1217,7 @@ int format_set_trailers_options(struct process_trailer_options *opts,
 static size_t parse_describe_args(const char *start, struct strvec *args)
 {
 	const char *options[] = { "tags" };
-	const char *option_arguments[] = { "match", "exclude" };
+	const char *option_arguments[] = { "match", "exclude", "abbrev" };
 	const char *arg = start;
 
 	for (;;) {
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index d4acf8882f..35eef4c865 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -1010,4 +1010,12 @@ test_expect_success '%(describe:tags) vs git describe --tags' '
 	test_cmp expect actual
 '
 
+test_expect_success '%(describe:abbrev=...) vs git describe --abbrev=...' '
+	test_when_finished "git tag -d tagname" &&
+	git tag -a -m tagged tagname &&
+	git describe --abbrev=15 >expect &&
+	git log -1 --format="%(describe:abbrev=15)" >actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.33.1

Re: [PATCH 3/3] pretty: add abbrev option to %(describe)

[Junio C Hamano]

Eli Schwartz <eschwartz@archlinux.org> writes:

> The %(describe) placeholder by default, like `git describe`, uses a
> seven-character abbreviated commit hash. This may not be sufficient to

"hash" -> "object name".

> fully describe all git repos, resulting in a placeholder replacement

"all git repos" -> "all commits in a given repository" (there may be
other valid way to clarify, but the point is that 'describe' does
not describe 'git repos' in the sense that my repository gets
description X while your repository gets description Y).

> changing its length because the repository grew in size. This could
> cause the output of git-archive to change.
>
> Add the --abbrev option to `git describe` to the placeholder interface
> in order to provide tools to the user for fine-tuning project defaults
> and ensure reproducible archives.

Note that it is sad that --abbrev=<n> does not necessarily ensure
reproducibility.  To be more precise, I do not think it sacrifices
uniqueness to make the output reproducible.  You can get more than N
hex-digits in the output if N is too small to ensure uniquness.

So it indeed is that this line of thought ...

> One alternative would be to just always specify --abbrev=40 but this may
> be a bit too biased...

... to use --abbrev=999 (because 40 is not the length of a full
object name in the SHA-2 world) is the only reasonable way, if what
you care about is the reproducibility.

    Side note.  I think "git describe --no-abbrev" is buggy in that
    it does not give a full object name; I didn't check the code,
    but it appears to be behaving the same way as "git describe
    --abbrev=0" (show no hexdigits).  Fixing this bug may possibly
    be a low-hanging fruit.

But even if the feature cannot be used to guarantee a full
reproducibility, it is a good thing that we can now add this feature
with minimum effort thanks to the previous two steps.

The refactoring I suggested in my review for the previous step will
shine, if we want to do a good job parsing the --abbrev=<n> option,
since such a code organization would make it a fairly easy addition
to introduce "integer" type that calls match_placeholder_arg_value()
to read the option value (like "string" does) and validate that the
value is indeed an integer.

Would we want to support "--contains" as another boolean type?  How
about "--all" and "--long"?  All three sound plausible candidates.

Thanks.

Re: [PATCH 3/3] pretty: add abbrev option to %(describe)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 4040 bytes --]

On 10/24/21 1:15 AM, Junio C Hamano wrote:
> Eli Schwartz <eschwartz@archlinux.org> writes:
> 
>> The %(describe) placeholder by default, like `git describe`, uses a
>> seven-character abbreviated commit hash. This may not be sufficient to
> 
> "hash" -> "object name".
> 
>> fully describe all git repos, resulting in a placeholder replacement
> 
> "all git repos" -> "all commits in a given repository" (there may be
> other valid way to clarify, but the point is that 'describe' does
> not describe 'git repos' in the sense that my repository gets
> description X while your repository gets description Y).


Good points.


>> changing its length because the repository grew in size. This could
>> cause the output of git-archive to change.
>>
>> Add the --abbrev option to `git describe` to the placeholder interface
>> in order to provide tools to the user for fine-tuning project defaults
>> and ensure reproducible archives.
> 
> Note that it is sad that --abbrev=<n> does not necessarily ensure
> reproducibility.  To be more precise, I do not think it sacrifices
> uniqueness to make the output reproducible.  You can get more than N
> hex-digits in the output if N is too small to ensure uniquness.
> 
> So it indeed is that this line of thought ...
> 
>> One alternative would be to just always specify --abbrev=40 but this may
>> be a bit too biased...
> 
> ... to use --abbrev=999 (because 40 is not the length of a full
> object name in the SHA-2 world) is the only reasonable way, if what
> you care about is the reproducibility.


Right, I keep forgetting about the current work towards SHA-2... that
being said I somehow feel that 40 hex-digits will probably be reasonably
sufficient even if commit object ids can become longer than that. So it
is technically true...


>     Side note.  I think "git describe --no-abbrev" is buggy in that
>     it does not give a full object name; I didn't check the code,
>     but it appears to be behaving the same way as "git describe
>     --abbrev=0" (show no hexdigits).  Fixing this bug may possibly
>     be a low-hanging fruit.


I... did not realize that --abbrev, which takes an integer value, could
be specified with a leading --no- in the first place. :o


> But even if the feature cannot be used to guarantee a full
> reproducibility, it is a good thing that we can now add this feature
> with minimum effort thanks to the previous two steps.
> 
> The refactoring I suggested in my review for the previous step will
> shine, if we want to do a good job parsing the --abbrev=<n> option,
> since such a code organization would make it a fairly easy addition
> to introduce "integer" type that calls match_placeholder_arg_value()
> to read the option value (like "string" does) and validate that the
> value is indeed an integer.
> 
> Would we want to support "--contains" as another boolean type?  How
> about "--all" and "--long"?  All three sound plausible candidates.


I didn't have any immediate use for these options. To be honest, I don't
entirely understand the purpose of:

--all, which causes git describe to report things like "heads/master"

--contains, which causes git describe to report different output
depending on the status of later commits being tagged


They may have their uses, but I'm not sure those uses include writing
metadata to a git-archive tarball at least. I believe the results would
inevitably end up changing after the fact, whereas only matching
existing tags will tend to be pretty reliable as a tag is, in most
(all?) cases, pushed at the same time as, or before:
- the commit it describes
- commits which are later than the tag


On the other hand...

--long could be interesting to some people, although for, say,
generating software version numbers, a tagged release will typically
omit that information in my experience. For the sake of thoroughness I
could add that too.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

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

[PATCH v2 0/3] Add some more options to the pretty-formats

[Eli Schwartz]

Here is the reworked implementation and all-new replacement first patch,
as suggested by review comments.

Minor tweaks to documentation in the second patch, otherwise
documentation and test cases are the same.

Eli Schwartz (3):
  pretty.c: rework describe options parsing for better extensibility
  pretty: add tag option to %(describe)
  pretty: add abbrev option to %(describe)

 Documentation/pretty-formats.txt | 16 +++++++---
 pretty.c                         | 55 ++++++++++++++++++++++++++------
 t/t4205-log-pretty-formats.sh    | 16 ++++++++++
 3 files changed, 72 insertions(+), 15 deletions(-)

-- 
2.33.1

[PATCH v2 1/3] pretty.c: rework describe options parsing for better extensibility

[Eli Schwartz]

It contains option arguments only, not options. We would like to add
option support here too, but to do that we need to distinguish between
different types of options.

Lay out the groundwork for distinguishing between bools, strings, etc.
and move the central logic (validating values and pushing new arguments
to *args) into the successful match, because that will be fairly
conditional on what type of argument is being parsed.

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
---
 pretty.c | 29 +++++++++++++++++++----------
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/pretty.c b/pretty.c
index 73b5ead509..f8b254d2ff 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1216,28 +1216,37 @@ int format_set_trailers_options(struct process_trailer_options *opts,
 
 static size_t parse_describe_args(const char *start, struct strvec *args)
 {
-	const char *options[] = { "match", "exclude" };
+	struct {
+		char *name;
+		enum { OPT_STRING } type;
+	}  option[] = {
+		{ "exclude", OPT_STRING },
+		{ "match", OPT_STRING },
+	};
 	const char *arg = start;
 
 	for (;;) {
-		const char *matched = NULL;
+		int found = 0;
 		const char *argval;
 		size_t arglen = 0;
 		int i;
 
-		for (i = 0; i < ARRAY_SIZE(options); i++) {
-			if (match_placeholder_arg_value(arg, options[i], &arg,
-							&argval, &arglen)) {
-				matched = options[i];
+		for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
+			switch(option[i].type) {
+			case OPT_STRING:
+				if (match_placeholder_arg_value(arg, option[i].name, &arg,
+								&argval, &arglen) && arglen) {
+					if (!arglen)
+						return 0;
+					strvec_pushf(args, "--%s=%.*s", option[i].name, (int)arglen, argval);
+					found = 1;
+				}
 				break;
 			}
 		}
-		if (!matched)
+		if (!found)
 			break;
 
-		if (!arglen)
-			return 0;
-		strvec_pushf(args, "--%s=%.*s", matched, (int)arglen, argval);
 	}
 	return arg - start;
 }
-- 
2.33.1

Re: [PATCH v2 1/3] pretty.c: rework describe options parsing for better extensibility

[Eric Sunshine]

On Mon, Oct 25, 2021 at 9:36 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
> It contains option arguments only, not options. We would like to add
> option support here too, but to do that we need to distinguish between
> different types of options.
>
> Lay out the groundwork for distinguishing between bools, strings, etc.
> and move the central logic (validating values and pushing new arguments
> to *args) into the successful match, because that will be fairly
> conditional on what type of argument is being parsed.
>
> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
> ---
> diff --git a/pretty.c b/pretty.c
> @@ -1216,28 +1216,37 @@ int format_set_trailers_options(struct process_trailer_options *opts,
>  static size_t parse_describe_args(const char *start, struct strvec *args)
>  {
> +       struct {
> +               char *name;
> +               enum { OPT_STRING } type;
> +       }  option[] = {
> +               { "exclude", OPT_STRING },
> +               { "match", OPT_STRING },
> +       };
>         const char *arg = start;
>
>         for (;;) {
> +               int found = 0;
>                 const char *argval;
>                 size_t arglen = 0;
>                 int i;
>
> +               for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
> +                       switch(option[i].type) {
> +                       case OPT_STRING:
> +                               if (match_placeholder_arg_value(arg, option[i].name, &arg,
> +                                                               &argval, &arglen) && arglen) {
> +                                       if (!arglen)
> +                                               return 0;

I may be missing something obvious, but how will it be possible for:

    if (!arglen)
        return 0;

to trigger if the `if` immediately above it:

    if (... && arglen) {

 has already asserted that `arglen` is not 0?

> +                                       strvec_pushf(args, "--%s=%.*s", option[i].name, (int)arglen, argval);
> +                                       found = 1;
> +                               }
>                                 break;
>                         }
>                 }
> +               if (!found)
>                         break;

The use of `found` to break out of a loop from within a `switch` seems
a bit clunky. An alternative would be to `goto` a label...

>         }
>         return arg - start;

... which could be introduced just before the `return`. Of course,
this is highly subjective, so not necessarily worth changing.

Re: [PATCH v2 1/3] pretty.c: rework describe options parsing for better extensibility

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 3523 bytes --]

On 10/26/21 1:18 AM, Eric Sunshine wrote:
> On Mon, Oct 25, 2021 at 9:36 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
>> It contains option arguments only, not options. We would like to add
>> option support here too, but to do that we need to distinguish between
>> different types of options.
>>
>> Lay out the groundwork for distinguishing between bools, strings, etc.
>> and move the central logic (validating values and pushing new arguments
>> to *args) into the successful match, because that will be fairly
>> conditional on what type of argument is being parsed.
>>
>> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
>> ---
>> diff --git a/pretty.c b/pretty.c
>> @@ -1216,28 +1216,37 @@ int format_set_trailers_options(struct process_trailer_options *opts,
>>  static size_t parse_describe_args(const char *start, struct strvec *args)
>>  {
>> +       struct {
>> +               char *name;
>> +               enum { OPT_STRING } type;
>> +       }  option[] = {
>> +               { "exclude", OPT_STRING },
>> +               { "match", OPT_STRING },
>> +       };
>>         const char *arg = start;
>>
>>         for (;;) {
>> +               int found = 0;
>>                 const char *argval;
>>                 size_t arglen = 0;
>>                 int i;
>>
>> +               for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
>> +                       switch(option[i].type) {
>> +                       case OPT_STRING:
>> +                               if (match_placeholder_arg_value(arg, option[i].name, &arg,
>> +                                                               &argval, &arglen) && arglen) {
>> +                                       if (!arglen)
>> +                                               return 0;
> 
> I may be missing something obvious, but how will it be possible for:
> 
>     if (!arglen)
>         return 0;
> 
> to trigger if the `if` immediately above it:
> 
>     if (... && arglen) {
> 
>  has already asserted that `arglen` is not 0?


I don't think you are missing anything here, I simply forgot that
halfway through I added a second check to the if, and later moved the
code from down below.

I think returning 0 is correct here, to avoid pointlessly checking the
rest of option[]. So I'll (re-)remove the first check.


>> +                                       strvec_pushf(args, "--%s=%.*s", option[i].name, (int)arglen, argval);
>> +                                       found = 1;
>> +                               }
>>                                 break;
>>                         }
>>                 }
>> +               if (!found)
>>                         break;
> 
> The use of `found` to break out of a loop from within a `switch` seems
> a bit clunky. An alternative would be to `goto` a label...
> 
>>         }
>>         return arg - start;
> 
> ... which could be introduced just before the `return`. Of course,
> this is highly subjective, so not necessarily worth changing.


Keeping in mind that this for (;;) { .... break; } was there before me
:D I just switched the name/type of the variable it checks...

IMO changing to goto is not my business to change (at least not in this
patch), and given the "common wisdom" is "goto is evil" I'm not strongly
inclined to get into the business of rewriting someone else's code for
that. It's too subjective for my taste.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

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

[PATCH v2 2/3] pretty: add tag option to %(describe)

[Eli Schwartz]

The %(describe) placeholder by default, like `git describe`, only
supports annotated tags. However, some people do use lightweight tags
for releases, and would like to describe those anyway. The command line
tool has an option to support this.

Teach the placeholder to support this as well.

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
---
 Documentation/pretty-formats.txt | 12 +++++++-----
 pretty.c                         | 14 +++++++++++++-
 t/t4205-log-pretty-formats.sh    |  8 ++++++++
 3 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index ef6bd420ae..86ed801aad 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -220,6 +220,8 @@ The placeholders are:
 			  inconsistent when tags are added or removed at
 			  the same time.
 +
+** 'tags[=<BOOL>]': Instead of only considering annotated tags,
+   consider lightweight tags as well.
 ** 'match=<pattern>': Only consider tags matching the given
    `glob(7)` pattern, excluding the "refs/tags/" prefix.
 ** 'exclude=<pattern>': Do not consider tags matching the given
@@ -273,11 +275,6 @@ endif::git-rev-list[]
 			  If any option is provided multiple times the
 			  last occurrence wins.
 +
-The boolean options accept an optional value `[=<BOOL>]`. The values
-`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
-sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
-option is given with no value, it's enabled.
-+
 ** 'key=<K>': only show trailers with specified key. Matching is done
    case-insensitively and trailing colon is optional. If option is
    given multiple times trailer lines matching any of the keys are
@@ -313,6 +310,11 @@ insert an empty string unless we are traversing reflog entries (e.g., by
 decoration format if `--decorate` was not already provided on the command
 line.
 
+The boolean options accept an optional value `[=<BOOL>]`. The values
+`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
+sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
+option is given with no value, it's enabled.
+
 If you add a `+` (plus sign) after '%' of a placeholder, a line-feed
 is inserted immediately before the expansion if and only if the
 placeholder expands to a non-empty string.
diff --git a/pretty.c b/pretty.c
index f8b254d2ff..16b5366fed 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1218,8 +1218,9 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 {
 	struct {
 		char *name;
-		enum { OPT_STRING } type;
+		enum { OPT_BOOL, OPT_STRING, } type;
 	}  option[] = {
+		{ "tags", OPT_BOOL},
 		{ "exclude", OPT_STRING },
 		{ "match", OPT_STRING },
 	};
@@ -1229,10 +1230,21 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 		int found = 0;
 		const char *argval;
 		size_t arglen = 0;
+		int optval = 0;
 		int i;
 
 		for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
 			switch(option[i].type) {
+			case OPT_BOOL:
+				if(match_placeholder_bool_arg(arg, option[i].name, &arg, &optval)) {
+					if (optval) {
+						strvec_pushf(args, "--%s", option[i].name);
+					} else {
+						strvec_pushf(args, "--no-%s", option[i].name);
+					}
+					found = 1;
+				}
+				break;
 			case OPT_STRING:
 				if (match_placeholder_arg_value(arg, option[i].name, &arg,
 								&argval, &arglen) && arglen) {
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 5865daa8f8..d4acf8882f 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -1002,4 +1002,12 @@ test_expect_success '%(describe:exclude=...) vs git describe --exclude ...' '
 	test_cmp expect actual
 '
 
+test_expect_success '%(describe:tags) vs git describe --tags' '
+	test_when_finished "git tag -d tagname" &&
+	git tag tagname &&
+	git describe --tags >expect &&
+	git log -1 --format="%(describe:tags)" >actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.33.1

Re: [PATCH v2 2/3] pretty: add tag option to %(describe)

[Eric Sunshine]

On Mon, Oct 25, 2021 at 9:36 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
> The %(describe) placeholder by default, like `git describe`, only
> supports annotated tags. However, some people do use lightweight tags
> for releases, and would like to describe those anyway. The command line
> tool has an option to support this.
>
> Teach the placeholder to support this as well.
>
> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
> ---
> diff --git a/pretty.c b/pretty.c
> @@ -1229,10 +1230,21 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
>                 for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
>                         switch(option[i].type) {
> +                       case OPT_BOOL:
> +                               if(match_placeholder_bool_arg(arg, option[i].name, &arg, &optval)) {

Style nit: add space after `if`

> +                                       if (optval) {
> +                                               strvec_pushf(args, "--%s", option[i].name);
> +                                       } else {
> +                                               strvec_pushf(args, "--no-%s", option[i].name);
> +                                       }

We would normally omit the braces for this simple `if`:

    if (optval)
        strvec_pushf(...);
    else
        strvec_pushf(...);

... or maybe even use the ternary operator:

    strvec_pushf(args, "--%s%s", optval ? "" : "no-", option[i].name);

but it's highly subjective whether or not that's more readable.

Re: [PATCH v2 2/3] pretty: add tag option to %(describe)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 2100 bytes --]

On 10/26/21 1:25 AM, Eric Sunshine wrote:
> On Mon, Oct 25, 2021 at 9:36 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
>> The %(describe) placeholder by default, like `git describe`, only
>> supports annotated tags. However, some people do use lightweight tags
>> for releases, and would like to describe those anyway. The command line
>> tool has an option to support this.
>>
>> Teach the placeholder to support this as well.
>>
>> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
>> ---
>> diff --git a/pretty.c b/pretty.c
>> @@ -1229,10 +1230,21 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
>>                 for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
>>                         switch(option[i].type) {
>> +                       case OPT_BOOL:
>> +                               if(match_placeholder_bool_arg(arg, option[i].name, &arg, &optval)) {
> 
> Style nit: add space after `if`


Oops, I am not sure how this happened. It's wrong in the switch too.


>> +                                       if (optval) {
>> +                                               strvec_pushf(args, "--%s", option[i].name);
>> +                                       } else {
>> +                                               strvec_pushf(args, "--no-%s", option[i].name);
>> +                                       }
> 
> We would normally omit the braces for this simple `if`:
> 
>     if (optval)
>         strvec_pushf(...);
>     else
>         strvec_pushf(...);
> 
> ... or maybe even use the ternary operator:
> 
>     strvec_pushf(args, "--%s%s", optval ? "" : "no-", option[i].name);
> 
> but it's highly subjective whether or not that's more readable.


Although the braces feel more natural to me for clarity purposes, it's a
good point that the git coding style says to omit them for single
statements, and I should have followed that here.

The ternary doesn't feel readable to me, however.

...

Thanks for the style review!

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

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

[PATCH v2 3/3] pretty: add abbrev option to %(describe)

[Eli Schwartz]

The %(describe) placeholder by default, like `git describe`, uses a
seven-character abbreviated commit object name. This may not be
sufficient to fully describe all commits in a given repository,
resulting in a placeholder replacement changing its length because the
repository grew in size.  This could cause the output of git-archive to
change.

Add the --abbrev option to `git describe` to the placeholder interface
in order to provide tools to the user for fine-tuning project defaults
and ensure reproducible archives.

One alternative would be to just always specify --abbrev=40 but this may
be a bit too biased...

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
---

Notes:
    With regard to validating that an integer is passed, I attempt to parse the
    result using the same mechanism git-describe itself does in the abbrev
    callback, just with slightly different validation of what we have at the end...
    because of course here argval is the entire rest of the format string,
    including the ")".
    
    While testing that this actually does what it's supposed to do, I noticed that
    it doesn't validate junk like leading whitespace or plus signs... this is a
    problem for `git describe --abbrev='    +15'` too so I guess it's not my
    problem to fix...

 Documentation/pretty-formats.txt |  4 ++++
 pretty.c                         | 16 +++++++++++++++-
 t/t4205-log-pretty-formats.sh    |  8 ++++++++
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 86ed801aad..57fd84f579 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -222,6 +222,10 @@ The placeholders are:
 +
 ** 'tags[=<BOOL>]': Instead of only considering annotated tags,
    consider lightweight tags as well.
+** 'abbrev=<N>': Instead of using the default number of hexadecimal digits
+   (which will vary according to the number of objects in the repository with a
+   default of 7) of the abbreviated object name, use <n> digits, or as many digits
+   as needed to form a unique object name.
 ** 'match=<pattern>': Only consider tags matching the given
    `glob(7)` pattern, excluding the "refs/tags/" prefix.
 ** 'exclude=<pattern>': Do not consider tags matching the given
diff --git a/pretty.c b/pretty.c
index 16b5366fed..44bfc49b38 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1218,9 +1218,10 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 {
 	struct {
 		char *name;
-		enum { OPT_BOOL, OPT_STRING, } type;
+		enum { OPT_BOOL, OPT_INTEGER, OPT_STRING, } type;
 	}  option[] = {
 		{ "tags", OPT_BOOL},
+		{ "abbrev", OPT_INTEGER },
 		{ "exclude", OPT_STRING },
 		{ "match", OPT_STRING },
 	};
@@ -1245,6 +1246,19 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 					found = 1;
 				}
 				break;
+			case OPT_INTEGER:
+				if (match_placeholder_arg_value(arg, option[i].name, &arg,
+								&argval, &arglen) && arglen) {
+					if (!arglen)
+						return 0;
+					char* endptr;
+					strtol(argval, &endptr, 10);
+					if (endptr - argval != arglen)
+						return 0;
+					strvec_pushf(args, "--%s=%.*s", option[i].name, (int)arglen, argval);
+					found = 1;
+				}
+				break;
 			case OPT_STRING:
 				if (match_placeholder_arg_value(arg, option[i].name, &arg,
 								&argval, &arglen) && arglen) {
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index d4acf8882f..35eef4c865 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -1010,4 +1010,12 @@ test_expect_success '%(describe:tags) vs git describe --tags' '
 	test_cmp expect actual
 '
 
+test_expect_success '%(describe:abbrev=...) vs git describe --abbrev=...' '
+	test_when_finished "git tag -d tagname" &&
+	git tag -a -m tagged tagname &&
+	git describe --abbrev=15 >expect &&
+	git log -1 --format="%(describe:abbrev=15)" >actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.33.1

Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe)

[Eric Sunshine]

On Mon, Oct 25, 2021 at 9:36 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
> The %(describe) placeholder by default, like `git describe`, uses a
> seven-character abbreviated commit object name. This may not be
> sufficient to fully describe all commits in a given repository,
> resulting in a placeholder replacement changing its length because the
> repository grew in size.  This could cause the output of git-archive to
> change.
>
> Add the --abbrev option to `git describe` to the placeholder interface
> in order to provide tools to the user for fine-tuning project defaults
> and ensure reproducible archives.
>
> One alternative would be to just always specify --abbrev=40 but this may
> be a bit too biased...
>
> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
> ---
> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> @@ -222,6 +222,10 @@ The placeholders are:
> +** 'abbrev=<N>': Instead of using the default number of hexadecimal digits
> +   (which will vary according to the number of objects in the repository with a
> +   default of 7) of the abbreviated object name, use <n> digits, or as many digits
> +   as needed to form a unique object name.

Inconsistent mix of `<N>` and `<n>`.

> diff --git a/pretty.c b/pretty.c
> @@ -1245,6 +1246,19 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
> +                       case OPT_INTEGER:
> +                               if (match_placeholder_arg_value(arg, option[i].name, &arg,
> +                                                               &argval, &arglen) && arglen) {
> +                                       if (!arglen)
> +                                               return 0;

Same question I asked while reviewing the other patch regarding
checking `arglen` in both conditionals: `if (... && arglen)` vs. `if
(!arglen)`

Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe)

[Đoàn Trần Công Danh]

On 2021-10-25 21:34:52-0400, Eli Schwartz <eschwartz@archlinux.org> wrote:
> The %(describe) placeholder by default, like `git describe`, uses a
> seven-character abbreviated commit object name. This may not be
> sufficient to fully describe all commits in a given repository,
> resulting in a placeholder replacement changing its length because the
> repository grew in size.  This could cause the output of git-archive to
> change.
> 
> Add the --abbrev option to `git describe` to the placeholder interface
> in order to provide tools to the user for fine-tuning project defaults
> and ensure reproducible archives.
> 
> One alternative would be to just always specify --abbrev=40 but this may
> be a bit too biased...
> 
> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
> ---
> 
> Notes:
>     With regard to validating that an integer is passed, I attempt to parse the
>     result using the same mechanism git-describe itself does in the abbrev
>     callback, just with slightly different validation of what we have at the end...
>     because of course here argval is the entire rest of the format string,
>     including the ")".
>     
>     While testing that this actually does what it's supposed to do, I noticed that
>     it doesn't validate junk like leading whitespace or plus signs... this is a
>     problem for `git describe --abbrev='    +15'` too so I guess it's not my
>     problem to fix...
> 
>  Documentation/pretty-formats.txt |  4 ++++
>  pretty.c                         | 16 +++++++++++++++-
>  t/t4205-log-pretty-formats.sh    |  8 ++++++++
>  3 files changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> index 86ed801aad..57fd84f579 100644
> --- a/Documentation/pretty-formats.txt
> +++ b/Documentation/pretty-formats.txt
> @@ -222,6 +222,10 @@ The placeholders are:
>  +
>  ** 'tags[=<BOOL>]': Instead of only considering annotated tags,
>     consider lightweight tags as well.
> +** 'abbrev=<N>': Instead of using the default number of hexadecimal digits
> +   (which will vary according to the number of objects in the repository with a
> +   default of 7) of the abbreviated object name, use <n> digits, or as many digits
> +   as needed to form a unique object name.
>  ** 'match=<pattern>': Only consider tags matching the given
>     `glob(7)` pattern, excluding the "refs/tags/" prefix.
>  ** 'exclude=<pattern>': Do not consider tags matching the given
> diff --git a/pretty.c b/pretty.c
> index 16b5366fed..44bfc49b38 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -1218,9 +1218,10 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
>  {
>  	struct {
>  		char *name;
> -		enum { OPT_BOOL, OPT_STRING, } type;
> +		enum { OPT_BOOL, OPT_INTEGER, OPT_STRING, } type;
>  	}  option[] = {
>  		{ "tags", OPT_BOOL},
> +		{ "abbrev", OPT_INTEGER },
>  		{ "exclude", OPT_STRING },
>  		{ "match", OPT_STRING },
>  	};
> @@ -1245,6 +1246,19 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
>  					found = 1;
>  				}
>  				break;
> +			case OPT_INTEGER:
> +				if (match_placeholder_arg_value(arg, option[i].name, &arg,
> +								&argval, &arglen) && arglen) {
> +					if (!arglen)
> +						return 0;
> +					char* endptr;

Other than the question pointed out by Eric,

with DEVELOPER=1, -Werror=declaration-after-statement
We'll need this change squashed in:

------- 8< -----
diff --git a/pretty.c b/pretty.c
index 289b5456c8..85d4ab008b 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1249,9 +1249,9 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 			case OPT_INTEGER:
 				if (match_placeholder_arg_value(arg, option[i].name, &arg,
 								&argval, &arglen) && arglen) {
+					char* endptr;
 					if (!arglen)
 						return 0;
-					char* endptr;
 					strtol(argval, &endptr, 10);
 					if (endptr - argval != arglen)
 						return 0;
------- >8 -----

> +					strtol(argval, &endptr, 10);
> +					if (endptr - argval != arglen)
> +						return 0;
> +					strvec_pushf(args, "--%s=%.*s", option[i].name, (int)arglen, argval);
> +					found = 1;
> +				}
> +				break;
>  			case OPT_STRING:
>  				if (match_placeholder_arg_value(arg, option[i].name, &arg,
>  								&argval, &arglen) && arglen) {
> diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
> index d4acf8882f..35eef4c865 100755
> --- a/t/t4205-log-pretty-formats.sh
> +++ b/t/t4205-log-pretty-formats.sh
> @@ -1010,4 +1010,12 @@ test_expect_success '%(describe:tags) vs git describe --tags' '
>  	test_cmp expect actual
>  '
>  
> +test_expect_success '%(describe:abbrev=...) vs git describe --abbrev=...' '
> +	test_when_finished "git tag -d tagname" &&
> +	git tag -a -m tagged tagname &&
> +	git describe --abbrev=15 >expect &&
> +	git log -1 --format="%(describe:abbrev=15)" >actual &&
> +	test_cmp expect actual
> +'
> +
>  test_done
> -- 
> 2.33.1
> 

-- 
Danh

Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe)

[Eric Sunshine]

On Tue, Oct 26, 2021 at 8:07 AM Đoàn Trần Công Danh
<congdanhqx@gmail.com> wrote:
> On 2021-10-25 21:34:52-0400, Eli Schwartz <eschwartz@archlinux.org> wrote:
> > +                                     if (!arglen)
> > +                                             return 0;
> > +                                     char* endptr;
>
> Other than the question pointed out by Eric,
>
> with DEVELOPER=1, -Werror=declaration-after-statement
> We'll need this change squashed in:
>
> +                                       char* endptr;
>                                         if (!arglen)
>                                                 return 0;
> -                                       char* endptr;

This highlights a style nit, as well; should be:

    char *endptr;

Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1724 bytes --]

On 10/26/21 8:06 AM, Đoàn Trần Công Danh wrote:
> Other than the question pointed out by Eric,
> 
> with DEVELOPER=1, -Werror=declaration-after-statement
> We'll need this change squashed in:


Thanks for the advice. In v1 of this patchset I attempted to do a
developer build but failed due to preexisting errors:


    CC run-command.o
run-command.c: In function ‘async_die_is_recursing’:
run-command.c:1102:9: error: ‘pthread_setspecific’ expecting 1 byte in a
region of size 0 [-Werror=stringop-overread]
 1102 |         pthread_setspecific(async_die_counter, (void *)1);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/openssl/crypto.h:415,
                 from /usr/include/openssl/comp.h:16,
                 from /usr/include/openssl/ssl.h:17,
                 from git-compat-util.h:309,
                 from cache.h:4,
                 from run-command.c:1:
/usr/include/pthread.h:1308:12: note: in a call to function
‘pthread_setspecific’ declared with attribute ‘access (none, 2)’
 1308 | extern int pthread_setspecific (pthread_key_t __key,
      |            ^~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors



My system has a custom compiled glibc from git roughly around the 2.34
release (a similar environment could be obtained by using Fedora rawhide
I guess), and this commit looks mighty suspicious:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a1561c3bbe8e72c6e44280d1eb5e529d2da4ecd0

For this reason, I did not bother to try testing v2 under a developer
build, leading to my overlooking this issue. ;)

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

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

Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe)

[Carlo Arenas]

On Wed, Oct 27, 2021 at 12:23 AM Eli Schwartz <eschwartz@archlinux.org> wrote:
>
> On 10/26/21 8:06 AM, Đoàn Trần Công Danh wrote:
> > Other than the question pointed out by Eric,
> >
> > with DEVELOPER=1, -Werror=declaration-after-statement
> > We'll need this change squashed in:
>
> Thanks for the advice. In v1 of this patchset I attempted to do a
> developer build but failed due to preexisting errors:

you can always avoid breaking your build by using:

  DEVOPTS=no-error

Carlo

Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe)

[Johannes Schindelin]

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

Hi Eli,

On Tue, 26 Oct 2021, Eli Schwartz wrote:

> On 10/26/21 8:06 AM, Đoàn Trần Công Danh wrote:
> > Other than the question pointed out by Eric,
> >
> > with DEVELOPER=1, -Werror=declaration-after-statement
> > We'll need this change squashed in:
>
>
> Thanks for the advice. In v1 of this patchset I attempted to do a
> developer build but failed due to preexisting errors:
>
>
>     CC run-command.o
> run-command.c: In function ‘async_die_is_recursing’:
> run-command.c:1102:9: error: ‘pthread_setspecific’ expecting 1 byte in a
> region of size 0 [-Werror=stringop-overread]
>  1102 |         pthread_setspecific(async_die_counter, (void *)1);
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from /usr/include/openssl/crypto.h:415,
>                  from /usr/include/openssl/comp.h:16,
>                  from /usr/include/openssl/ssl.h:17,
>                  from git-compat-util.h:309,
>                  from cache.h:4,
>                  from run-command.c:1:
> /usr/include/pthread.h:1308:12: note: in a call to function
> ‘pthread_setspecific’ declared with attribute ‘access (none, 2)’
>  1308 | extern int pthread_setspecific (pthread_key_t __key,
>       |            ^~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
>
>
> My system has a custom compiled glibc from git roughly around the 2.34
> release (a similar environment could be obtained by using Fedora rawhide
> I guess), and this commit looks mighty suspicious:
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a1561c3bbe8e72c6e44280d1eb5e529d2da4ecd0
>
> For this reason, I did not bother to try testing v2 under a developer
> build, leading to my overlooking this issue. ;)

It seems that this issue now hit an official version. As I explained in
https://lore.kernel.org/git/nycvar.QRO.7.76.6.2111040007170.56@tvgsbejvaqbjf.bet/T/#u,
my colleague Victoria Dye will send a fix for this later.

Stay tuned,
Johannes

Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe)

[Johannes Schindelin]

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

Hi Eli,

On Thu, 4 Nov 2021, Johannes Schindelin wrote:

> On Tue, 26 Oct 2021, Eli Schwartz wrote:
>
> > On 10/26/21 8:06 AM, Đoàn Trần Công Danh wrote:
> > > Other than the question pointed out by Eric,
> > >
> > > with DEVELOPER=1, -Werror=declaration-after-statement
> > > We'll need this change squashed in:
> >
> >
> > Thanks for the advice. In v1 of this patchset I attempted to do a
> > developer build but failed due to preexisting errors:
> >
> >
> >     CC run-command.o
> > run-command.c: In function ‘async_die_is_recursing’:
> > run-command.c:1102:9: error: ‘pthread_setspecific’ expecting 1 byte in a
> > region of size 0 [-Werror=stringop-overread]
> >  1102 |         pthread_setspecific(async_die_counter, (void *)1);
> >       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from /usr/include/openssl/crypto.h:415,
> >                  from /usr/include/openssl/comp.h:16,
> >                  from /usr/include/openssl/ssl.h:17,
> >                  from git-compat-util.h:309,
> >                  from cache.h:4,
> >                  from run-command.c:1:
> > /usr/include/pthread.h:1308:12: note: in a call to function
> > ‘pthread_setspecific’ declared with attribute ‘access (none, 2)’
> >  1308 | extern int pthread_setspecific (pthread_key_t __key,
> >       |            ^~~~~~~~~~~~~~~~~~~
> > cc1: all warnings being treated as errors
> >
> >
> >
> > My system has a custom compiled glibc from git roughly around the 2.34
> > release (a similar environment could be obtained by using Fedora rawhide
> > I guess), and this commit looks mighty suspicious:
> > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a1561c3bbe8e72c6e44280d1eb5e529d2da4ecd0
> >
> > For this reason, I did not bother to try testing v2 under a developer
> > build, leading to my overlooking this issue. ;)
>
> It seems that this issue now hit an official version. As I explained in
> https://lore.kernel.org/git/nycvar.QRO.7.76.6.2111040007170.56@tvgsbejvaqbjf.bet/T/#u,
> my colleague Victoria Dye will send a fix for this later.

FYI here is the patch:
https://lore.kernel.org/git/pull.1072.v2.git.1635998463474.gitgitgadget@gmail.com/

Ciao,
Johannes

Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1047 bytes --]

On 11/3/21 7:20 PM, Johannes Schindelin wrote:
> Hi Eli,
> 
> On Tue, 26 Oct 2021, Eli Schwartz wrote:
> 
>> My system has a custom compiled glibc from git roughly around the 2.34
>> release (a similar environment could be obtained by using Fedora rawhide
>> I guess), and this commit looks mighty suspicious:
>> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a1561c3bbe8e72c6e44280d1eb5e529d2da4ecd0
>>
>> For this reason, I did not bother to try testing v2 under a developer
>> build, leading to my overlooking this issue. ;)
> 
> It seems that this issue now hit an official version. As I explained in
> https://lore.kernel.org/git/nycvar.QRO.7.76.6.2111040007170.56@tvgsbejvaqbjf.bet/T/#u,
> my colleague Victoria Dye will send a fix for this later.
> 
> Stay tuned,


FWIW this was present in the official version of glibc released in
August... the problem is finding an official version of a distro that
ships it. :D

Thanks for the heads up.


-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

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

[PATCH v3 0/3] Add some more options to the pretty-formats

[Eli Schwartz]

This revision only contains style nits in response to review comments.
See below.

Eli Schwartz (3):
  pretty.c: rework describe options parsing for better extensibility
  pretty: add tag option to %(describe)
  pretty: add abbrev option to %(describe)

 Documentation/pretty-formats.txt | 16 +++++++---
 pretty.c                         | 54 ++++++++++++++++++++++++++------
 t/t4205-log-pretty-formats.sh    | 16 ++++++++++
 3 files changed, 71 insertions(+), 15 deletions(-)

Range-diff against v2:
1:  1cf0d82b91 ! 1:  55a20468d3 pretty.c: rework describe options parsing for better extensibility
    @@ pretty.c: int format_set_trailers_options(struct process_trailer_options *opts,
     -							&argval, &arglen)) {
     -				matched = options[i];
     +		for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
    -+			switch(option[i].type) {
    ++			switch (option[i].type) {
     +			case OPT_STRING:
     +				if (match_placeholder_arg_value(arg, option[i].name, &arg,
    -+								&argval, &arglen) && arglen) {
    ++								&argval, &arglen)) {
     +					if (!arglen)
     +						return 0;
     +					strvec_pushf(args, "--%s=%.*s", option[i].name, (int)arglen, argval);
2:  cb6af9bc14 ! 2:  c34c8a4f7f pretty: add tag option to %(describe)
    @@ pretty.c: static size_t parse_describe_args(const char *start, struct strvec *ar
      		int i;
      
      		for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
    - 			switch(option[i].type) {
    + 			switch (option[i].type) {
     +			case OPT_BOOL:
    -+				if(match_placeholder_bool_arg(arg, option[i].name, &arg, &optval)) {
    -+					if (optval) {
    ++				if (match_placeholder_bool_arg(arg, option[i].name, &arg, &optval)) {
    ++					if (optval)
     +						strvec_pushf(args, "--%s", option[i].name);
    -+					} else {
    ++					else
     +						strvec_pushf(args, "--no-%s", option[i].name);
    -+					}
     +					found = 1;
     +				}
     +				break;
      			case OPT_STRING:
      				if (match_placeholder_arg_value(arg, option[i].name, &arg,
    - 								&argval, &arglen) && arglen) {
    + 								&argval, &arglen)) {
     
      ## t/t4205-log-pretty-formats.sh ##
     @@ t/t4205-log-pretty-formats.sh: test_expect_success '%(describe:exclude=...) vs git describe --exclude ...' '
3:  08ade18b35 ! 3:  b751aaf3c6 pretty: add abbrev option to %(describe)
    @@ pretty.c: static size_t parse_describe_args(const char *start, struct strvec *ar
      				break;
     +			case OPT_INTEGER:
     +				if (match_placeholder_arg_value(arg, option[i].name, &arg,
    -+								&argval, &arglen) && arglen) {
    ++								&argval, &arglen)) {
    ++					char *endptr;
     +					if (!arglen)
     +						return 0;
    -+					char* endptr;
     +					strtol(argval, &endptr, 10);
     +					if (endptr - argval != arglen)
     +						return 0;
    @@ pretty.c: static size_t parse_describe_args(const char *start, struct strvec *ar
     +				break;
      			case OPT_STRING:
      				if (match_placeholder_arg_value(arg, option[i].name, &arg,
    - 								&argval, &arglen) && arglen) {
    + 								&argval, &arglen)) {
     
      ## t/t4205-log-pretty-formats.sh ##
     @@ t/t4205-log-pretty-formats.sh: test_expect_success '%(describe:tags) vs git describe --tags' '
-- 
2.33.1

[PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility

[Eli Schwartz]

It contains option arguments only, not options. We would like to add
option support here too, but to do that we need to distinguish between
different types of options.

Lay out the groundwork for distinguishing between bools, strings, etc.
and move the central logic (validating values and pushing new arguments
to *args) into the successful match, because that will be fairly
conditional on what type of argument is being parsed.

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
---
 pretty.c | 29 +++++++++++++++++++----------
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/pretty.c b/pretty.c
index fe95107ae5..2ec023a0d0 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1216,28 +1216,37 @@ int format_set_trailers_options(struct process_trailer_options *opts,
 
 static size_t parse_describe_args(const char *start, struct strvec *args)
 {
-	const char *options[] = { "match", "exclude" };
+	struct {
+		char *name;
+		enum { OPT_STRING } type;
+	}  option[] = {
+		{ "exclude", OPT_STRING },
+		{ "match", OPT_STRING },
+	};
 	const char *arg = start;
 
 	for (;;) {
-		const char *matched = NULL;
+		int found = 0;
 		const char *argval;
 		size_t arglen = 0;
 		int i;
 
-		for (i = 0; i < ARRAY_SIZE(options); i++) {
-			if (match_placeholder_arg_value(arg, options[i], &arg,
-							&argval, &arglen)) {
-				matched = options[i];
+		for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
+			switch (option[i].type) {
+			case OPT_STRING:
+				if (match_placeholder_arg_value(arg, option[i].name, &arg,
+								&argval, &arglen)) {
+					if (!arglen)
+						return 0;
+					strvec_pushf(args, "--%s=%.*s", option[i].name, (int)arglen, argval);
+					found = 1;
+				}
 				break;
 			}
 		}
-		if (!matched)
+		if (!found)
 			break;
 
-		if (!arglen)
-			return 0;
-		strvec_pushf(args, "--%s=%.*s", matched, (int)arglen, argval);
 	}
 	return arg - start;
 }
-- 
2.33.1

Re: [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility

[Junio C Hamano]

Eli Schwartz <eschwartz@archlinux.org> writes:

> +	struct {
> +		char *name;
> +		enum { OPT_STRING } type;
> +	}  option[] = {
> +		{ "exclude", OPT_STRING },
> +		{ "match", OPT_STRING },
> +	};

I floated OPT_<TYPE> in my earlier illustration as "something like
this", not "literally use these tokens".  We have CPP macros of the
same name in parse-options.h API---we may not see troubles from the
name clashes today, but let's not leave it to chances.

Perhaps call it like DESCRBE_ARG_STRING or something that ensures
uniqueness like that?

Thanks.

Re: [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 932 bytes --]

On 10/29/21 4:11 PM, Junio C Hamano wrote:
> Eli Schwartz <eschwartz@archlinux.org> writes:
> 
>> +	struct {
>> +		char *name;
>> +		enum { OPT_STRING } type;
>> +	}  option[] = {
>> +		{ "exclude", OPT_STRING },
>> +		{ "match", OPT_STRING },
>> +	};
> 
> I floated OPT_<TYPE> in my earlier illustration as "something like
> this", not "literally use these tokens".  We have CPP macros of the
> same name in parse-options.h API---we may not see troubles from the
> name clashes today, but let's not leave it to chances.
> 
> Perhaps call it like DESCRBE_ARG_STRING or something that ensures
> uniqueness like that?


Ah. That alternative seems a bit long though. :( Without breaking enum
type into one per line, it will quickly overflow line lengths... though
maybe it should be one per line anyway?

Will try to put some thought into naming.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

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

Re: [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility

[Junio C Hamano]

Eli Schwartz <eschwartz@archlinux.org> writes:

> On 10/29/21 4:11 PM, Junio C Hamano wrote:
>> Eli Schwartz <eschwartz@archlinux.org> writes:
>> 
>>> +	struct {
>>> +		char *name;
>>> +		enum { OPT_STRING } type;
>>> +	}  option[] = {
>>> +		{ "exclude", OPT_STRING },
>>> +		{ "match", OPT_STRING },
>>> +	};
>> 
>> I floated OPT_<TYPE> in my earlier illustration as "something like
>> this", not "literally use these tokens".  We have CPP macros of the
>> same name in parse-options.h API---we may not see troubles from the
>> name clashes today, but let's not leave it to chances.
>> 
>> Perhaps call it like DESCRBE_ARG_STRING or something that ensures
>> uniqueness like that?
>
>
> Ah. That alternative seems a bit long though. :( Without breaking enum
> type into one per line, it will quickly overflow line lengths... though
> maybe it should be one per line anyway?

Yes, these things should be one item per line; a patch that adds or
removes one would become easier to read.

>
> Will try to put some thought into naming.

[PATCH v3 2/3] pretty: add tag option to %(describe)

[Eli Schwartz]

The %(describe) placeholder by default, like `git describe`, only
supports annotated tags. However, some people do use lightweight tags
for releases, and would like to describe those anyway. The command line
tool has an option to support this.

Teach the placeholder to support this as well.

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
---
 Documentation/pretty-formats.txt | 12 +++++++-----
 pretty.c                         | 13 ++++++++++++-
 t/t4205-log-pretty-formats.sh    |  8 ++++++++
 3 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index ef6bd420ae..86ed801aad 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -220,6 +220,8 @@ The placeholders are:
 			  inconsistent when tags are added or removed at
 			  the same time.
 +
+** 'tags[=<BOOL>]': Instead of only considering annotated tags,
+   consider lightweight tags as well.
 ** 'match=<pattern>': Only consider tags matching the given
    `glob(7)` pattern, excluding the "refs/tags/" prefix.
 ** 'exclude=<pattern>': Do not consider tags matching the given
@@ -273,11 +275,6 @@ endif::git-rev-list[]
 			  If any option is provided multiple times the
 			  last occurrence wins.
 +
-The boolean options accept an optional value `[=<BOOL>]`. The values
-`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
-sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
-option is given with no value, it's enabled.
-+
 ** 'key=<K>': only show trailers with specified key. Matching is done
    case-insensitively and trailing colon is optional. If option is
    given multiple times trailer lines matching any of the keys are
@@ -313,6 +310,11 @@ insert an empty string unless we are traversing reflog entries (e.g., by
 decoration format if `--decorate` was not already provided on the command
 line.
 
+The boolean options accept an optional value `[=<BOOL>]`. The values
+`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
+sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
+option is given with no value, it's enabled.
+
 If you add a `+` (plus sign) after '%' of a placeholder, a line-feed
 is inserted immediately before the expansion if and only if the
 placeholder expands to a non-empty string.
diff --git a/pretty.c b/pretty.c
index 2ec023a0d0..a105ef2a15 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1218,8 +1218,9 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 {
 	struct {
 		char *name;
-		enum { OPT_STRING } type;
+		enum { OPT_BOOL, OPT_STRING, } type;
 	}  option[] = {
+		{ "tags", OPT_BOOL},
 		{ "exclude", OPT_STRING },
 		{ "match", OPT_STRING },
 	};
@@ -1229,10 +1230,20 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 		int found = 0;
 		const char *argval;
 		size_t arglen = 0;
+		int optval = 0;
 		int i;
 
 		for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
 			switch (option[i].type) {
+			case OPT_BOOL:
+				if (match_placeholder_bool_arg(arg, option[i].name, &arg, &optval)) {
+					if (optval)
+						strvec_pushf(args, "--%s", option[i].name);
+					else
+						strvec_pushf(args, "--no-%s", option[i].name);
+					found = 1;
+				}
+				break;
 			case OPT_STRING:
 				if (match_placeholder_arg_value(arg, option[i].name, &arg,
 								&argval, &arglen)) {
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 5865daa8f8..d4acf8882f 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -1002,4 +1002,12 @@ test_expect_success '%(describe:exclude=...) vs git describe --exclude ...' '
 	test_cmp expect actual
 '
 
+test_expect_success '%(describe:tags) vs git describe --tags' '
+	test_when_finished "git tag -d tagname" &&
+	git tag tagname &&
+	git describe --tags >expect &&
+	git log -1 --format="%(describe:tags)" >actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.33.1

Re: [PATCH v3 2/3] pretty: add tag option to %(describe)

[Junio C Hamano]

Eli Schwartz <eschwartz@archlinux.org> writes:

>  +
> +** 'tags[=<BOOL>]': Instead of only considering annotated tags,
> +   consider lightweight tags as well.

This part contradicts what Jean-Noël's df34a41f is trying to
achieve, which can be seen in these hunks from it:

    @@ -273,12 +273,12 @@ endif::git-rev-list[]
                              If any option is provided multiple times the
                              last occurrence wins.
     +
    -The boolean options accept an optional value `[=<BOOL>]`. The values
    +The boolean options accept an optional value `[=<value>]`. The values
     `true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
     sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
     option is given with no value, it's enabled.
     +
    -** 'key=<K>': only show trailers with specified key. Matching is done
    +** 'key=<key>': only show trailers with specified <key>. Matching is done
        case-insensitively and trailing colon is optional. If option is
        given multiple times trailer lines matching any of the keys are
        shown. This option automatically enables the `only` option so that
    @@ -286,25 +286,25 @@ option is given with no value, it's enabled.
        desired it can be disabled with `only=false`.  E.g.,
        `%(trailers:key=Reviewed-by)` shows trailer lines with key
        `Reviewed-by`.
    -** 'only[=<BOOL>]': select whether non-trailer lines from the trailer
    +** 'only[=<bool-value>]': select whether non-trailer lines from the trailer
        block should be included.
    -** 'separator=<SEP>': specify a separator inserted between trailer
    +** 'separator=<sep>': specify a separator inserted between trailer
     ...


So, let's instead use

    tags[=<bool-value>]: Instead of only considering ...

i.e. lowercase, with -value suffix.

Thanks.

Re: [PATCH v3 2/3] pretty: add tag option to %(describe)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1034 bytes --]

On 10/29/21 4:18 PM, Junio C Hamano wrote:
> Eli Schwartz <eschwartz@archlinux.org> writes:
> 
>>  +
>> +** 'tags[=<BOOL>]': Instead of only considering annotated tags,
>> +   consider lightweight tags as well.
> 
> This part contradicts what Jean-Noël's df34a41f is trying to
> achieve, which can be seen in these hunks from it:
>
> [...]
> 
> So, let's instead use
> 
>     tags[=<bool-value>]: Instead of only considering ...
> 
> i.e. lowercase, with -value suffix.


An interesting change. I can use that description style, sure. Though I
will note the commit message for it talks a lot about replacing spaces
with hyphens, and very little about consolidating on case *or* using
different language such as:


-* 'format:<string>'
+* 'format:<format-string>'


I also assume that it's fine for my patches to be inconsistent with the
base commit, as it's expected df34a41f or some revision of it will be
merged around the same time?


-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

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

Re: [PATCH v3 2/3] pretty: add tag option to %(describe)

[Junio C Hamano]

Eli Schwartz <eschwartz@archlinux.org> writes:

> I also assume that it's fine for my patches to be inconsistent with the
> base commit, as it's expected df34a41f or some revision of it will be
> merged around the same time?

Yes, such inconsistencies will be gone when the both topics get
merged.  You can just assume that the details of what you write may
not matter in the end result ;-)

Or perhaps the other topic would graduate first, in which case you
have a chance to rebase these patches on top of the 'master' that
already have the other topic.  Your patches would then be consistent
with the base commit, as the base would already be cleaned up.

Thanks.

Re: [PATCH v3 2/3] pretty: add tag option to %(describe)

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Eli Schwartz <eschwartz@archlinux.org> writes:
>
>>  +
>> +** 'tags[=<BOOL>]': Instead of only considering annotated tags,
>> +   consider lightweight tags as well.
>
> This part contradicts what Jean-Noël's df34a41f is trying to
> achieve, which can be seen in these hunks from it:
> ...
> So, let's instead use
>
>     tags[=<bool-value>]: Instead of only considering ...
>
> i.e. lowercase, with -value suffix.

The other topic merges earlier to 'seen' before your topic, and FYI,
the diff between the tip of 'seen' before and after your topic gets
merged looks like this, with my semantic conflict resolution.

Notice the way placeholders are spelled in lowercase and generally
have more descriptive names.

Thanks.

diff --git c/Documentation/pretty-formats.txt w/Documentation/pretty-formats.txt
index d465cd59dd..25cfffab38 100644
--- c/Documentation/pretty-formats.txt
+++ w/Documentation/pretty-formats.txt
@@ -220,6 +220,12 @@ The placeholders are:
 			  inconsistent when tags are added or removed at
 			  the same time.
 +
+** 'tags[=<bool-value>]': Instead of only considering annotated tags,
+   consider lightweight tags as well.
+** 'abbrev=<number>': Instead of using the default number of hexadecimal digits
+   (which will vary according to the number of objects in the repository with a
+   default of 7) of the abbreviated object name, use <number> digits, or as many digits
+   as needed to form a unique object name.
 ** 'match=<pattern>': Only consider tags matching the given
    `glob(7)` pattern, excluding the "refs/tags/" prefix.
 ** 'exclude=<pattern>': Do not consider tags matching the given
@@ -273,11 +279,6 @@ endif::git-rev-list[]
 			  If any option is provided multiple times the
 			  last occurrence wins.
 +
-The boolean options accept an optional value `[=<value>]`. The values
-`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
-sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
-option is given with no value, it's enabled.
-+
 ** 'key=<key>': only show trailers with specified <key>. Matching is done
    case-insensitively and trailing colon is optional. If option is
    given multiple times trailer lines matching any of the keys are
@@ -313,6 +314,11 @@ insert an empty string unless we are traversing reflog entries (e.g., by
 decoration format if `--decorate` was not already provided on the command
 line.
 
+The boolean options accept an optional value `[=<bool-value>]`. The values
+`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
+sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
+option is given with no value, it's enabled.
+
 If you add a `+` (plus sign) after '%' of a placeholder, a line-feed
 is inserted immediately before the expansion if and only if the
 placeholder expands to a non-empty string.

Re: [PATCH v3 2/3] pretty: add tag option to %(describe)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1588 bytes --]

On 10/29/21 5:28 PM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Eli Schwartz <eschwartz@archlinux.org> writes:
>>
>>>  +
>>> +** 'tags[=<BOOL>]': Instead of only considering annotated tags,
>>> +   consider lightweight tags as well.
>>
>> This part contradicts what Jean-Noël's df34a41f is trying to
>> achieve, which can be seen in these hunks from it:
>> ...
>> So, let's instead use
>>
>>     tags[=<bool-value>]: Instead of only considering ...
>>
>> i.e. lowercase, with -value suffix.
> 
> The other topic merges earlier to 'seen' before your topic, and FYI,
> the diff between the tip of 'seen' before and after your topic gets
> merged looks like this, with my semantic conflict resolution.
> 
> Notice the way placeholders are spelled in lowercase and generally
> have more descriptive names.
> 
> Thanks.
> 
> diff --git c/Documentation/pretty-formats.txt w/Documentation/pretty-formats.txt
> index d465cd59dd..25cfffab38 100644
> --- c/Documentation/pretty-formats.txt
> +++ w/Documentation/pretty-formats.txt
> @@ -220,6 +220,12 @@ The placeholders are:
>  			  inconsistent when tags are added or removed at
>  			  the same time.
>  +
> +** 'tags[=<bool-value>]': Instead of only considering annotated tags,
> +   consider lightweight tags as well.
> +** 'abbrev=<number>': Instead of using the default number of hexadecimal digits


As a matter of curiosity, why "bool-value" but not "number-value"?

Isn't the "value" part implicit?


-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

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

[PATCH v3 3/3] pretty: add abbrev option to %(describe)

[Eli Schwartz]

The %(describe) placeholder by default, like `git describe`, uses a
seven-character abbreviated commit object name. This may not be
sufficient to fully describe all commits in a given repository,
resulting in a placeholder replacement changing its length because the
repository grew in size.  This could cause the output of git-archive to
change.

Add the --abbrev option to `git describe` to the placeholder interface
in order to provide tools to the user for fine-tuning project defaults
and ensure reproducible archives.

One alternative would be to just always specify --abbrev=40 but this may
be a bit too biased...

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
---
 Documentation/pretty-formats.txt |  4 ++++
 pretty.c                         | 16 +++++++++++++++-
 t/t4205-log-pretty-formats.sh    |  8 ++++++++
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 86ed801aad..57fd84f579 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -222,6 +222,10 @@ The placeholders are:
 +
 ** 'tags[=<BOOL>]': Instead of only considering annotated tags,
    consider lightweight tags as well.
+** 'abbrev=<N>': Instead of using the default number of hexadecimal digits
+   (which will vary according to the number of objects in the repository with a
+   default of 7) of the abbreviated object name, use <n> digits, or as many digits
+   as needed to form a unique object name.
 ** 'match=<pattern>': Only consider tags matching the given
    `glob(7)` pattern, excluding the "refs/tags/" prefix.
 ** 'exclude=<pattern>': Do not consider tags matching the given
diff --git a/pretty.c b/pretty.c
index a105ef2a15..5662cb2943 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1218,9 +1218,10 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 {
 	struct {
 		char *name;
-		enum { OPT_BOOL, OPT_STRING, } type;
+		enum { OPT_BOOL, OPT_INTEGER, OPT_STRING, } type;
 	}  option[] = {
 		{ "tags", OPT_BOOL},
+		{ "abbrev", OPT_INTEGER },
 		{ "exclude", OPT_STRING },
 		{ "match", OPT_STRING },
 	};
@@ -1244,6 +1245,19 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 					found = 1;
 				}
 				break;
+			case OPT_INTEGER:
+				if (match_placeholder_arg_value(arg, option[i].name, &arg,
+								&argval, &arglen)) {
+					char *endptr;
+					if (!arglen)
+						return 0;
+					strtol(argval, &endptr, 10);
+					if (endptr - argval != arglen)
+						return 0;
+					strvec_pushf(args, "--%s=%.*s", option[i].name, (int)arglen, argval);
+					found = 1;
+				}
+				break;
 			case OPT_STRING:
 				if (match_placeholder_arg_value(arg, option[i].name, &arg,
 								&argval, &arglen)) {
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index d4acf8882f..35eef4c865 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -1010,4 +1010,12 @@ test_expect_success '%(describe:tags) vs git describe --tags' '
 	test_cmp expect actual
 '
 
+test_expect_success '%(describe:abbrev=...) vs git describe --abbrev=...' '
+	test_when_finished "git tag -d tagname" &&
+	git tag -a -m tagged tagname &&
+	git describe --abbrev=15 >expect &&
+	git log -1 --format="%(describe:abbrev=15)" >actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.33.1

Re: [PATCH v3 3/3] pretty: add abbrev option to %(describe)

[Eric Sunshine]

On Fri, Oct 29, 2021 at 2:45 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
> The %(describe) placeholder by default, like `git describe`, uses a
> seven-character abbreviated commit object name. This may not be
> sufficient to fully describe all commits in a given repository,
> resulting in a placeholder replacement changing its length because the
> repository grew in size.  This could cause the output of git-archive to
> change.
>
> Add the --abbrev option to `git describe` to the placeholder interface
> in order to provide tools to the user for fine-tuning project defaults
> and ensure reproducible archives.
> [...]
> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
> ---
> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> @@ -222,6 +222,10 @@ The placeholders are:
> +** 'abbrev=<N>': Instead of using the default number of hexadecimal digits
> +   (which will vary according to the number of objects in the repository with a
> +   default of 7) of the abbreviated object name, use <n> digits, or as many digits
> +   as needed to form a unique object name.

There's still an inconsistent mix of `<N>` and `<n>` here (mentioned
in my earlier review). Is that intentional or just a simple oversight?

Re: [PATCH v3 3/3] pretty: add abbrev option to %(describe)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1652 bytes --]

On 10/29/21 2:51 PM, Eric Sunshine wrote:
> On Fri, Oct 29, 2021 at 2:45 PM Eli Schwartz <eschwartz@archlinux.org> wrote:
>> The %(describe) placeholder by default, like `git describe`, uses a
>> seven-character abbreviated commit object name. This may not be
>> sufficient to fully describe all commits in a given repository,
>> resulting in a placeholder replacement changing its length because the
>> repository grew in size.  This could cause the output of git-archive to
>> change.
>>
>> Add the --abbrev option to `git describe` to the placeholder interface
>> in order to provide tools to the user for fine-tuning project defaults
>> and ensure reproducible archives.
>> [...]
>> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
>> ---
>> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
>> @@ -222,6 +222,10 @@ The placeholders are:
>> +** 'abbrev=<N>': Instead of using the default number of hexadecimal digits
>> +   (which will vary according to the number of objects in the repository with a
>> +   default of 7) of the abbreviated object name, use <n> digits, or as many digits
>> +   as needed to form a unique object name.
> 
> There's still an inconsistent mix of `<N>` and `<n>` here (mentioned
> in my earlier review). Is that intentional or just a simple oversight?


Ah, sorry... I overlooked that. It was originally copied from the
git-describe man page which uses lowercase and I overlooked that part of
your review.

It should be consistently uppercase here for consistency with
pretty-formats.


-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

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

[PATCH v4 0/3] Add some more options to the pretty-formats

[Eli Schwartz]

Renamed enum values. OPT_ -> DESCRIBE_ARG_
Doc fixups.

Eli Schwartz (3):
  pretty.c: rework describe options parsing for better extensibility
  pretty: add tag option to %(describe)
  pretty: add abbrev option to %(describe)

 Documentation/pretty-formats.txt | 16 ++++++---
 pretty.c                         | 58 ++++++++++++++++++++++++++------
 t/t4205-log-pretty-formats.sh    | 16 +++++++++
 3 files changed, 75 insertions(+), 15 deletions(-)

Range-diff against v3:
1:  55a20468d3 ! 1:  be35fee252 pretty.c: rework describe options parsing for better extensibility
    @@ pretty.c: int format_set_trailers_options(struct process_trailer_options *opts,
     -	const char *options[] = { "match", "exclude" };
     +	struct {
     +		char *name;
    -+		enum { OPT_STRING } type;
    ++		enum {
    ++			DESCRIBE_ARG_STRING,
    ++		} type;
     +	}  option[] = {
    -+		{ "exclude", OPT_STRING },
    -+		{ "match", OPT_STRING },
    ++		{ "exclude", DESCRIBE_ARG_STRING },
    ++		{ "match", DESCRIBE_ARG_STRING },
     +	};
      	const char *arg = start;
      
    @@ pretty.c: int format_set_trailers_options(struct process_trailer_options *opts,
     -				matched = options[i];
     +		for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
     +			switch (option[i].type) {
    -+			case OPT_STRING:
    ++			case DESCRIBE_ARG_STRING:
     +				if (match_placeholder_arg_value(arg, option[i].name, &arg,
     +								&argval, &arglen)) {
     +					if (!arglen)
2:  c34c8a4f7f ! 2:  5830c69d4d pretty: add tag option to %(describe)
    @@ Documentation/pretty-formats.txt: The placeholders are:
      			  inconsistent when tags are added or removed at
      			  the same time.
      +
    -+** 'tags[=<BOOL>]': Instead of only considering annotated tags,
    ++** 'tags[=<bool>]': Instead of only considering annotated tags,
     +   consider lightweight tags as well.
      ** 'match=<pattern>': Only consider tags matching the given
         `glob(7)` pattern, excluding the "refs/tags/" prefix.
    @@ Documentation/pretty-formats.txt: insert an empty string unless we are traversin
      decoration format if `--decorate` was not already provided on the command
      line.
      
    -+The boolean options accept an optional value `[=<BOOL>]`. The values
    ++The boolean options accept an optional value `[=<bool>]`. The values
     +`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
     +sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
     +option is given with no value, it's enabled.
    @@ Documentation/pretty-formats.txt: insert an empty string unless we are traversin
     
      ## pretty.c ##
     @@ pretty.c: static size_t parse_describe_args(const char *start, struct strvec *args)
    - {
      	struct {
      		char *name;
    --		enum { OPT_STRING } type;
    -+		enum { OPT_BOOL, OPT_STRING, } type;
    + 		enum {
    ++			DESCRIBE_ARG_BOOL,
    + 			DESCRIBE_ARG_STRING,
    + 		} type;
      	}  option[] = {
    -+		{ "tags", OPT_BOOL},
    - 		{ "exclude", OPT_STRING },
    - 		{ "match", OPT_STRING },
    ++		{ "tags", DESCRIBE_ARG_BOOL},
    + 		{ "exclude", DESCRIBE_ARG_STRING },
    + 		{ "match", DESCRIBE_ARG_STRING },
      	};
     @@ pretty.c: static size_t parse_describe_args(const char *start, struct strvec *args)
      		int found = 0;
    @@ pretty.c: static size_t parse_describe_args(const char *start, struct strvec *ar
      
      		for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
      			switch (option[i].type) {
    -+			case OPT_BOOL:
    ++			case DESCRIBE_ARG_BOOL:
     +				if (match_placeholder_bool_arg(arg, option[i].name, &arg, &optval)) {
     +					if (optval)
     +						strvec_pushf(args, "--%s", option[i].name);
    @@ pretty.c: static size_t parse_describe_args(const char *start, struct strvec *ar
     +					found = 1;
     +				}
     +				break;
    - 			case OPT_STRING:
    + 			case DESCRIBE_ARG_STRING:
      				if (match_placeholder_arg_value(arg, option[i].name, &arg,
      								&argval, &arglen)) {
     
3:  b751aaf3c6 ! 3:  032513150d pretty: add abbrev option to %(describe)
    @@ Commit message
      ## Documentation/pretty-formats.txt ##
     @@ Documentation/pretty-formats.txt: The placeholders are:
      +
    - ** 'tags[=<BOOL>]': Instead of only considering annotated tags,
    + ** 'tags[=<bool>]': Instead of only considering annotated tags,
         consider lightweight tags as well.
    -+** 'abbrev=<N>': Instead of using the default number of hexadecimal digits
    ++** 'abbrev=<number>': Instead of using the default number of hexadecimal digits
     +   (which will vary according to the number of objects in the repository with a
    -+   default of 7) of the abbreviated object name, use <n> digits, or as many digits
    -+   as needed to form a unique object name.
    ++   default of 7) of the abbreviated object name, use <number> digits, or as many
    ++   digits as needed to form a unique object name.
      ** 'match=<pattern>': Only consider tags matching the given
         `glob(7)` pattern, excluding the "refs/tags/" prefix.
      ** 'exclude=<pattern>': Do not consider tags matching the given
     
      ## pretty.c ##
     @@ pretty.c: static size_t parse_describe_args(const char *start, struct strvec *args)
    - {
    - 	struct {
      		char *name;
    --		enum { OPT_BOOL, OPT_STRING, } type;
    -+		enum { OPT_BOOL, OPT_INTEGER, OPT_STRING, } type;
    + 		enum {
    + 			DESCRIBE_ARG_BOOL,
    ++			DESCRIBE_ARG_INTEGER,
    + 			DESCRIBE_ARG_STRING,
    + 		} type;
      	}  option[] = {
    - 		{ "tags", OPT_BOOL},
    -+		{ "abbrev", OPT_INTEGER },
    - 		{ "exclude", OPT_STRING },
    - 		{ "match", OPT_STRING },
    + 		{ "tags", DESCRIBE_ARG_BOOL},
    ++		{ "abbrev", DESCRIBE_ARG_INTEGER },
    + 		{ "exclude", DESCRIBE_ARG_STRING },
    + 		{ "match", DESCRIBE_ARG_STRING },
      	};
     @@ pretty.c: static size_t parse_describe_args(const char *start, struct strvec *args)
      					found = 1;
      				}
      				break;
    -+			case OPT_INTEGER:
    ++			case DESCRIBE_ARG_INTEGER:
     +				if (match_placeholder_arg_value(arg, option[i].name, &arg,
     +								&argval, &arglen)) {
     +					char *endptr;
    @@ pretty.c: static size_t parse_describe_args(const char *start, struct strvec *ar
     +					found = 1;
     +				}
     +				break;
    - 			case OPT_STRING:
    + 			case DESCRIBE_ARG_STRING:
      				if (match_placeholder_arg_value(arg, option[i].name, &arg,
      								&argval, &arglen)) {
     
-- 
2.33.1

[PATCH v4 1/3] pretty.c: rework describe options parsing for better extensibility

[Eli Schwartz]

It contains option arguments only, not options. We would like to add
option support here too, but to do that we need to distinguish between
different types of options.

Lay out the groundwork for distinguishing between bools, strings, etc.
and move the central logic (validating values and pushing new arguments
to *args) into the successful match, because that will be fairly
conditional on what type of argument is being parsed.

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
---
 pretty.c | 31 +++++++++++++++++++++----------
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/pretty.c b/pretty.c
index be477bd51f..c38acda8cb 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1212,28 +1212,39 @@ int format_set_trailers_options(struct process_trailer_options *opts,
 
 static size_t parse_describe_args(const char *start, struct strvec *args)
 {
-	const char *options[] = { "match", "exclude" };
+	struct {
+		char *name;
+		enum {
+			DESCRIBE_ARG_STRING,
+		} type;
+	}  option[] = {
+		{ "exclude", DESCRIBE_ARG_STRING },
+		{ "match", DESCRIBE_ARG_STRING },
+	};
 	const char *arg = start;
 
 	for (;;) {
-		const char *matched = NULL;
+		int found = 0;
 		const char *argval;
 		size_t arglen = 0;
 		int i;
 
-		for (i = 0; i < ARRAY_SIZE(options); i++) {
-			if (match_placeholder_arg_value(arg, options[i], &arg,
-							&argval, &arglen)) {
-				matched = options[i];
+		for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
+			switch (option[i].type) {
+			case DESCRIBE_ARG_STRING:
+				if (match_placeholder_arg_value(arg, option[i].name, &arg,
+								&argval, &arglen)) {
+					if (!arglen)
+						return 0;
+					strvec_pushf(args, "--%s=%.*s", option[i].name, (int)arglen, argval);
+					found = 1;
+				}
 				break;
 			}
 		}
-		if (!matched)
+		if (!found)
 			break;
 
-		if (!arglen)
-			return 0;
-		strvec_pushf(args, "--%s=%.*s", matched, (int)arglen, argval);
 	}
 	return arg - start;
 }
-- 
2.33.1

[PATCH v4 2/3] pretty: add tag option to %(describe)

[Eli Schwartz]

The %(describe) placeholder by default, like `git describe`, only
supports annotated tags. However, some people do use lightweight tags
for releases, and would like to describe those anyway. The command line
tool has an option to support this.

Teach the placeholder to support this as well.

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
---

I use lowercase "bool" here not "boolean-value" because I don't see
utility in the word "value" here.

 Documentation/pretty-formats.txt | 12 +++++++-----
 pretty.c                         | 12 ++++++++++++
 t/t4205-log-pretty-formats.sh    |  8 ++++++++
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index ef6bd420ae..1ee47bd4a3 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -220,6 +220,8 @@ The placeholders are:
 			  inconsistent when tags are added or removed at
 			  the same time.
 +
+** 'tags[=<bool>]': Instead of only considering annotated tags,
+   consider lightweight tags as well.
 ** 'match=<pattern>': Only consider tags matching the given
    `glob(7)` pattern, excluding the "refs/tags/" prefix.
 ** 'exclude=<pattern>': Do not consider tags matching the given
@@ -273,11 +275,6 @@ endif::git-rev-list[]
 			  If any option is provided multiple times the
 			  last occurrence wins.
 +
-The boolean options accept an optional value `[=<BOOL>]`. The values
-`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
-sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
-option is given with no value, it's enabled.
-+
 ** 'key=<K>': only show trailers with specified key. Matching is done
    case-insensitively and trailing colon is optional. If option is
    given multiple times trailer lines matching any of the keys are
@@ -313,6 +310,11 @@ insert an empty string unless we are traversing reflog entries (e.g., by
 decoration format if `--decorate` was not already provided on the command
 line.
 
+The boolean options accept an optional value `[=<bool>]`. The values
+`true`, `false`, `on`, `off` etc. are all accepted. See the "boolean"
+sub-section in "EXAMPLES" in linkgit:git-config[1]. If a boolean
+option is given with no value, it's enabled.
+
 If you add a `+` (plus sign) after '%' of a placeholder, a line-feed
 is inserted immediately before the expansion if and only if the
 placeholder expands to a non-empty string.
diff --git a/pretty.c b/pretty.c
index c38acda8cb..403d89725a 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1215,9 +1215,11 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 	struct {
 		char *name;
 		enum {
+			DESCRIBE_ARG_BOOL,
 			DESCRIBE_ARG_STRING,
 		} type;
 	}  option[] = {
+		{ "tags", DESCRIBE_ARG_BOOL},
 		{ "exclude", DESCRIBE_ARG_STRING },
 		{ "match", DESCRIBE_ARG_STRING },
 	};
@@ -1227,10 +1229,20 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 		int found = 0;
 		const char *argval;
 		size_t arglen = 0;
+		int optval = 0;
 		int i;
 
 		for (i = 0; !found && i < ARRAY_SIZE(option); i++) {
 			switch (option[i].type) {
+			case DESCRIBE_ARG_BOOL:
+				if (match_placeholder_bool_arg(arg, option[i].name, &arg, &optval)) {
+					if (optval)
+						strvec_pushf(args, "--%s", option[i].name);
+					else
+						strvec_pushf(args, "--no-%s", option[i].name);
+					found = 1;
+				}
+				break;
 			case DESCRIBE_ARG_STRING:
 				if (match_placeholder_arg_value(arg, option[i].name, &arg,
 								&argval, &arglen)) {
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 5865daa8f8..d4acf8882f 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -1002,4 +1002,12 @@ test_expect_success '%(describe:exclude=...) vs git describe --exclude ...' '
 	test_cmp expect actual
 '
 
+test_expect_success '%(describe:tags) vs git describe --tags' '
+	test_when_finished "git tag -d tagname" &&
+	git tag tagname &&
+	git describe --tags >expect &&
+	git log -1 --format="%(describe:tags)" >actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.33.1

Re: [PATCH v4 2/3] pretty: add tag option to %(describe)

[Junio C Hamano]

Eli Schwartz <eschwartz@archlinux.org> writes:

> The %(describe) placeholder by default, like `git describe`, only
> supports annotated tags. However, some people do use lightweight tags
> for releases, and would like to describe those anyway. The command line
> tool has an option to support this.
>
> Teach the placeholder to support this as well.
>
> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
> ---
>
> I use lowercase "bool" here not "boolean-value" because I don't see
> utility in the word "value" here.

Such a comment is much more useful if it is sent as a review to the
patch that touches the same area as your patch does, namely,

https://lore.kernel.org/git/984b6d687a2e779c775de6ea80536afe6ecc0aaf.1635438124.git.gitgitgadget@gmail.com/

not here.

Thanks.

[jc: added a few folks involved in the other patch to the addressee
lists]

Re: [PATCH v4 2/3] pretty: add tag option to %(describe)

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 1030 bytes --]

On 10/31/21 2:07 PM, Junio C Hamano wrote:
> Eli Schwartz <eschwartz@archlinux.org> writes:
> 
>> The %(describe) placeholder by default, like `git describe`, only
>> supports annotated tags. However, some people do use lightweight tags
>> for releases, and would like to describe those anyway. The command line
>> tool has an option to support this.
>>
>> Teach the placeholder to support this as well.
>>
>> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
>> ---
>>
>> I use lowercase "bool" here not "boolean-value" because I don't see
>> utility in the word "value" here.
> 
> Such a comment is much more useful if it is sent as a review to the
> patch that touches the same area as your patch does, namely,
> 
> https://lore.kernel.org/git/984b6d687a2e779c775de6ea80536afe6ecc0aaf.1635438124.git.gitgitgadget@gmail.com/
> 
> not here.


Indeed, done. (I had to unexpectedly step away for a bit after sending
my updated series.)


-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

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

[PATCH v4 3/3] pretty: add abbrev option to %(describe)

[Eli Schwartz]

The %(describe) placeholder by default, like `git describe`, uses a
seven-character abbreviated commit object name. This may not be
sufficient to fully describe all commits in a given repository,
resulting in a placeholder replacement changing its length because the
repository grew in size.  This could cause the output of git-archive to
change.

Add the --abbrev option to `git describe` to the placeholder interface
in order to provide tools to the user for fine-tuning project defaults
and ensure reproducible archives.

One alternative would be to just always specify --abbrev=40 but this may
be a bit too biased...

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
---
 Documentation/pretty-formats.txt |  4 ++++
 pretty.c                         | 15 +++++++++++++++
 t/t4205-log-pretty-formats.sh    |  8 ++++++++
 3 files changed, 27 insertions(+)

diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 1ee47bd4a3..9e943fb74b 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -222,6 +222,10 @@ The placeholders are:
 +
 ** 'tags[=<bool>]': Instead of only considering annotated tags,
    consider lightweight tags as well.
+** 'abbrev=<number>': Instead of using the default number of hexadecimal digits
+   (which will vary according to the number of objects in the repository with a
+   default of 7) of the abbreviated object name, use <number> digits, or as many
+   digits as needed to form a unique object name.
 ** 'match=<pattern>': Only consider tags matching the given
    `glob(7)` pattern, excluding the "refs/tags/" prefix.
 ** 'exclude=<pattern>': Do not consider tags matching the given
diff --git a/pretty.c b/pretty.c
index 403d89725a..fa9bfea273 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1216,10 +1216,12 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 		char *name;
 		enum {
 			DESCRIBE_ARG_BOOL,
+			DESCRIBE_ARG_INTEGER,
 			DESCRIBE_ARG_STRING,
 		} type;
 	}  option[] = {
 		{ "tags", DESCRIBE_ARG_BOOL},
+		{ "abbrev", DESCRIBE_ARG_INTEGER },
 		{ "exclude", DESCRIBE_ARG_STRING },
 		{ "match", DESCRIBE_ARG_STRING },
 	};
@@ -1243,6 +1245,19 @@ static size_t parse_describe_args(const char *start, struct strvec *args)
 					found = 1;
 				}
 				break;
+			case DESCRIBE_ARG_INTEGER:
+				if (match_placeholder_arg_value(arg, option[i].name, &arg,
+								&argval, &arglen)) {
+					char *endptr;
+					if (!arglen)
+						return 0;
+					strtol(argval, &endptr, 10);
+					if (endptr - argval != arglen)
+						return 0;
+					strvec_pushf(args, "--%s=%.*s", option[i].name, (int)arglen, argval);
+					found = 1;
+				}
+				break;
 			case DESCRIBE_ARG_STRING:
 				if (match_placeholder_arg_value(arg, option[i].name, &arg,
 								&argval, &arglen)) {
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index d4acf8882f..35eef4c865 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -1010,4 +1010,12 @@ test_expect_success '%(describe:tags) vs git describe --tags' '
 	test_cmp expect actual
 '
 
+test_expect_success '%(describe:abbrev=...) vs git describe --abbrev=...' '
+	test_when_finished "git tag -d tagname" &&
+	git tag -a -m tagged tagname &&
+	git describe --abbrev=15 >expect &&
+	git log -1 --format="%(describe:abbrev=15)" >actual &&
+	test_cmp expect actual
+'
+
 test_done
-- 
2.33.1