* [PATCH 0/3] Add some more options to the pretty-formats @ 2021-10-24 1:42 Eli Schwartz 2021-10-24 1:42 ` [PATCH 1/3] pretty.c: rename describe options variable to more descriptive name Eli Schwartz ` (3 more replies) 0 siblings, 4 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-24 1:42 UTC (permalink / raw) To: git; +Cc: René Scharfe 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 1/3] pretty.c: rename describe options variable to more descriptive name 2021-10-24 1:42 [PATCH 0/3] Add some more options to the pretty-formats Eli Schwartz @ 2021-10-24 1:42 ` Eli Schwartz 2021-10-24 4:31 ` Junio C Hamano 2021-10-24 1:42 ` [PATCH 2/3] pretty: add tag option to %(describe) Eli Schwartz ` (2 subsequent siblings) 3 siblings, 1 reply; 46+ messages in thread From: Eli Schwartz @ 2021-10-24 1:42 UTC (permalink / raw) To: git; +Cc: René Scharfe 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 1/3] pretty.c: rename describe options variable to more descriptive name 2021-10-24 1:42 ` [PATCH 1/3] pretty.c: rename describe options variable to more descriptive name Eli Schwartz @ 2021-10-24 4:31 ` Junio C Hamano 2021-10-24 15:37 ` Eli Schwartz 0 siblings, 1 reply; 46+ messages in thread From: Junio C Hamano @ 2021-10-24 4:31 UTC (permalink / raw) To: Eli Schwartz; +Cc: git, René Scharfe 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; > } > } ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 1/3] pretty.c: rename describe options variable to more descriptive name 2021-10-24 4:31 ` Junio C Hamano @ 2021-10-24 15:37 ` Eli Schwartz 0 siblings, 0 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-24 15:37 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, René Scharfe [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 2/3] pretty: add tag option to %(describe) 2021-10-24 1:42 [PATCH 0/3] Add some more options to the pretty-formats Eli Schwartz 2021-10-24 1:42 ` [PATCH 1/3] pretty.c: rename describe options variable to more descriptive name Eli Schwartz @ 2021-10-24 1:42 ` Eli Schwartz 2021-10-24 4:57 ` Junio C Hamano 2021-10-24 1:42 ` [PATCH 3/3] pretty: add abbrev " Eli Schwartz 2021-10-26 1:34 ` [PATCH v2 0/3] Add some more options to the pretty-formats Eli Schwartz 3 siblings, 1 reply; 46+ messages in thread From: Eli Schwartz @ 2021-10-24 1:42 UTC (permalink / raw) To: git; +Cc: René Scharfe 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 2/3] pretty: add tag option to %(describe) 2021-10-24 1:42 ` [PATCH 2/3] pretty: add tag option to %(describe) Eli Schwartz @ 2021-10-24 4:57 ` Junio C Hamano 2021-10-24 15:38 ` Eli Schwartz 0 siblings, 1 reply; 46+ messages in thread From: Junio C Hamano @ 2021-10-24 4:57 UTC (permalink / raw) To: Eli Schwartz; +Cc: git, René Scharfe 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 2/3] pretty: add tag option to %(describe) 2021-10-24 4:57 ` Junio C Hamano @ 2021-10-24 15:38 ` Eli Schwartz 0 siblings, 0 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-24 15:38 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, René Scharfe [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 3/3] pretty: add abbrev option to %(describe) 2021-10-24 1:42 [PATCH 0/3] Add some more options to the pretty-formats Eli Schwartz 2021-10-24 1:42 ` [PATCH 1/3] pretty.c: rename describe options variable to more descriptive name Eli Schwartz 2021-10-24 1:42 ` [PATCH 2/3] pretty: add tag option to %(describe) Eli Schwartz @ 2021-10-24 1:42 ` Eli Schwartz 2021-10-24 5:15 ` Junio C Hamano 2021-10-26 1:34 ` [PATCH v2 0/3] Add some more options to the pretty-formats Eli Schwartz 3 siblings, 1 reply; 46+ messages in thread From: Eli Schwartz @ 2021-10-24 1:42 UTC (permalink / raw) To: git; +Cc: René Scharfe 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 3/3] pretty: add abbrev option to %(describe) 2021-10-24 1:42 ` [PATCH 3/3] pretty: add abbrev " Eli Schwartz @ 2021-10-24 5:15 ` Junio C Hamano 2021-10-24 15:43 ` Eli Schwartz 0 siblings, 1 reply; 46+ messages in thread From: Junio C Hamano @ 2021-10-24 5:15 UTC (permalink / raw) To: Eli Schwartz; +Cc: git, René Scharfe 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 3/3] pretty: add abbrev option to %(describe) 2021-10-24 5:15 ` Junio C Hamano @ 2021-10-24 15:43 ` Eli Schwartz 0 siblings, 0 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-24 15:43 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, René Scharfe [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2 0/3] Add some more options to the pretty-formats 2021-10-24 1:42 [PATCH 0/3] Add some more options to the pretty-formats Eli Schwartz ` (2 preceding siblings ...) 2021-10-24 1:42 ` [PATCH 3/3] pretty: add abbrev " Eli Schwartz @ 2021-10-26 1:34 ` Eli Schwartz 2021-10-26 1:34 ` [PATCH v2 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz ` (3 more replies) 3 siblings, 4 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-26 1:34 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2 1/3] pretty.c: rework describe options parsing for better extensibility 2021-10-26 1:34 ` [PATCH v2 0/3] Add some more options to the pretty-formats Eli Schwartz @ 2021-10-26 1:34 ` Eli Schwartz 2021-10-26 5:18 ` Eric Sunshine 2021-10-26 1:34 ` [PATCH v2 2/3] pretty: add tag option to %(describe) Eli Schwartz ` (2 subsequent siblings) 3 siblings, 1 reply; 46+ messages in thread From: Eli Schwartz @ 2021-10-26 1:34 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v2 1/3] pretty.c: rework describe options parsing for better extensibility 2021-10-26 1:34 ` [PATCH v2 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz @ 2021-10-26 5:18 ` Eric Sunshine 2021-10-26 20:05 ` Eli Schwartz 0 siblings, 1 reply; 46+ messages in thread From: Eric Sunshine @ 2021-10-26 5:18 UTC (permalink / raw) To: Eli Schwartz; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 1/3] pretty.c: rework describe options parsing for better extensibility 2021-10-26 5:18 ` Eric Sunshine @ 2021-10-26 20:05 ` Eli Schwartz 0 siblings, 0 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-26 20:05 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2 2/3] pretty: add tag option to %(describe) 2021-10-26 1:34 ` [PATCH v2 0/3] Add some more options to the pretty-formats Eli Schwartz 2021-10-26 1:34 ` [PATCH v2 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz @ 2021-10-26 1:34 ` Eli Schwartz 2021-10-26 5:25 ` Eric Sunshine 2021-10-26 1:34 ` [PATCH v2 3/3] pretty: add abbrev " Eli Schwartz 2021-10-29 18:45 ` [PATCH v3 0/3] Add some more options to the pretty-formats Eli Schwartz 3 siblings, 1 reply; 46+ messages in thread From: Eli Schwartz @ 2021-10-26 1:34 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/3] pretty: add tag option to %(describe) 2021-10-26 1:34 ` [PATCH v2 2/3] pretty: add tag option to %(describe) Eli Schwartz @ 2021-10-26 5:25 ` Eric Sunshine 2021-10-26 20:06 ` Eli Schwartz 0 siblings, 1 reply; 46+ messages in thread From: Eric Sunshine @ 2021-10-26 5:25 UTC (permalink / raw) To: Eli Schwartz; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 2/3] pretty: add tag option to %(describe) 2021-10-26 5:25 ` Eric Sunshine @ 2021-10-26 20:06 ` Eli Schwartz 0 siblings, 0 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-26 20:06 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v2 3/3] pretty: add abbrev option to %(describe) 2021-10-26 1:34 ` [PATCH v2 0/3] Add some more options to the pretty-formats Eli Schwartz 2021-10-26 1:34 ` [PATCH v2 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz 2021-10-26 1:34 ` [PATCH v2 2/3] pretty: add tag option to %(describe) Eli Schwartz @ 2021-10-26 1:34 ` Eli Schwartz 2021-10-26 5:36 ` Eric Sunshine 2021-10-26 12:06 ` Đoàn Trần Công Danh 2021-10-29 18:45 ` [PATCH v3 0/3] Add some more options to the pretty-formats Eli Schwartz 3 siblings, 2 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-26 1:34 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe) 2021-10-26 1:34 ` [PATCH v2 3/3] pretty: add abbrev " Eli Schwartz @ 2021-10-26 5:36 ` Eric Sunshine 2021-10-26 12:06 ` Đoàn Trần Công Danh 1 sibling, 0 replies; 46+ messages in thread From: Eric Sunshine @ 2021-10-26 5:36 UTC (permalink / raw) To: Eli Schwartz; +Cc: Git List 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)` ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe) 2021-10-26 1:34 ` [PATCH v2 3/3] pretty: add abbrev " Eli Schwartz 2021-10-26 5:36 ` Eric Sunshine @ 2021-10-26 12:06 ` Đoàn Trần Công Danh 2021-10-26 17:28 ` Eric Sunshine 2021-10-26 19:12 ` Eli Schwartz 1 sibling, 2 replies; 46+ messages in thread From: Đoàn Trần Công Danh @ 2021-10-26 12:06 UTC (permalink / raw) To: Eli Schwartz; +Cc: git 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe) 2021-10-26 12:06 ` Đoàn Trần Công Danh @ 2021-10-26 17:28 ` Eric Sunshine 2021-10-26 19:12 ` Eli Schwartz 1 sibling, 0 replies; 46+ messages in thread From: Eric Sunshine @ 2021-10-26 17:28 UTC (permalink / raw) To: Đoàn Trần Công Danh; +Cc: Eli Schwartz, Git List 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; ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe) 2021-10-26 12:06 ` Đoàn Trần Công Danh 2021-10-26 17:28 ` Eric Sunshine @ 2021-10-26 19:12 ` Eli Schwartz 2021-10-27 8:05 ` Carlo Arenas 2021-11-03 23:20 ` Johannes Schindelin 1 sibling, 2 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-26 19:12 UTC (permalink / raw) To: Đoàn Trần Công Danh; +Cc: git [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe) 2021-10-26 19:12 ` Eli Schwartz @ 2021-10-27 8:05 ` Carlo Arenas 2021-11-03 23:20 ` Johannes Schindelin 1 sibling, 0 replies; 46+ messages in thread From: Carlo Arenas @ 2021-10-27 8:05 UTC (permalink / raw) To: Eli Schwartz; +Cc: Đoàn Trần Công Danh, git 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe) 2021-10-26 19:12 ` Eli Schwartz 2021-10-27 8:05 ` Carlo Arenas @ 2021-11-03 23:20 ` Johannes Schindelin 2021-11-04 9:29 ` Johannes Schindelin 2021-11-07 12:39 ` Eli Schwartz 1 sibling, 2 replies; 46+ messages in thread From: Johannes Schindelin @ 2021-11-03 23:20 UTC (permalink / raw) To: Eli Schwartz; +Cc: Đoàn Trần Công Danh, git [-- 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe) 2021-11-03 23:20 ` Johannes Schindelin @ 2021-11-04 9:29 ` Johannes Schindelin 2021-11-07 12:39 ` Eli Schwartz 1 sibling, 0 replies; 46+ messages in thread From: Johannes Schindelin @ 2021-11-04 9:29 UTC (permalink / raw) To: Eli Schwartz; +Cc: Đoàn Trần Công Danh, git [-- 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v2 3/3] pretty: add abbrev option to %(describe) 2021-11-03 23:20 ` Johannes Schindelin 2021-11-04 9:29 ` Johannes Schindelin @ 2021-11-07 12:39 ` Eli Schwartz 1 sibling, 0 replies; 46+ messages in thread From: Eli Schwartz @ 2021-11-07 12:39 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Đoàn Trần Công Danh, git [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 0/3] Add some more options to the pretty-formats 2021-10-26 1:34 ` [PATCH v2 0/3] Add some more options to the pretty-formats Eli Schwartz ` (2 preceding siblings ...) 2021-10-26 1:34 ` [PATCH v2 3/3] pretty: add abbrev " Eli Schwartz @ 2021-10-29 18:45 ` Eli Schwartz 2021-10-29 18:45 ` [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz ` (3 more replies) 3 siblings, 4 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-29 18:45 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility 2021-10-29 18:45 ` [PATCH v3 0/3] Add some more options to the pretty-formats Eli Schwartz @ 2021-10-29 18:45 ` Eli Schwartz 2021-10-29 20:11 ` Junio C Hamano 2021-10-29 18:45 ` [PATCH v3 2/3] pretty: add tag option to %(describe) Eli Schwartz ` (2 subsequent siblings) 3 siblings, 1 reply; 46+ messages in thread From: Eli Schwartz @ 2021-10-29 18:45 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility 2021-10-29 18:45 ` [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz @ 2021-10-29 20:11 ` Junio C Hamano 2021-10-29 21:06 ` Eli Schwartz 0 siblings, 1 reply; 46+ messages in thread From: Junio C Hamano @ 2021-10-29 20:11 UTC (permalink / raw) To: Eli Schwartz; +Cc: git 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility 2021-10-29 20:11 ` Junio C Hamano @ 2021-10-29 21:06 ` Eli Schwartz 2021-10-29 21:34 ` Junio C Hamano 0 siblings, 1 reply; 46+ messages in thread From: Eli Schwartz @ 2021-10-29 21:06 UTC (permalink / raw) To: Junio C Hamano; +Cc: git [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility 2021-10-29 21:06 ` Eli Schwartz @ 2021-10-29 21:34 ` Junio C Hamano 0 siblings, 0 replies; 46+ messages in thread From: Junio C Hamano @ 2021-10-29 21:34 UTC (permalink / raw) To: Eli Schwartz; +Cc: git 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 2/3] pretty: add tag option to %(describe) 2021-10-29 18:45 ` [PATCH v3 0/3] Add some more options to the pretty-formats Eli Schwartz 2021-10-29 18:45 ` [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz @ 2021-10-29 18:45 ` Eli Schwartz 2021-10-29 20:18 ` Junio C Hamano 2021-10-29 18:45 ` [PATCH v3 3/3] pretty: add abbrev " Eli Schwartz 2021-10-31 17:15 ` [PATCH v4 0/3] Add some more options to the pretty-formats Eli Schwartz 3 siblings, 1 reply; 46+ messages in thread From: Eli Schwartz @ 2021-10-29 18:45 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/3] pretty: add tag option to %(describe) 2021-10-29 18:45 ` [PATCH v3 2/3] pretty: add tag option to %(describe) Eli Schwartz @ 2021-10-29 20:18 ` Junio C Hamano 2021-10-29 21:14 ` Eli Schwartz 2021-10-29 21:28 ` Junio C Hamano 0 siblings, 2 replies; 46+ messages in thread From: Junio C Hamano @ 2021-10-29 20:18 UTC (permalink / raw) To: Eli Schwartz; +Cc: git 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/3] pretty: add tag option to %(describe) 2021-10-29 20:18 ` Junio C Hamano @ 2021-10-29 21:14 ` Eli Schwartz 2021-10-29 21:46 ` Junio C Hamano 2021-10-29 21:28 ` Junio C Hamano 1 sibling, 1 reply; 46+ messages in thread From: Eli Schwartz @ 2021-10-29 21:14 UTC (permalink / raw) To: Junio C Hamano; +Cc: git [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/3] pretty: add tag option to %(describe) 2021-10-29 21:14 ` Eli Schwartz @ 2021-10-29 21:46 ` Junio C Hamano 0 siblings, 0 replies; 46+ messages in thread From: Junio C Hamano @ 2021-10-29 21:46 UTC (permalink / raw) To: Eli Schwartz; +Cc: git 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/3] pretty: add tag option to %(describe) 2021-10-29 20:18 ` Junio C Hamano 2021-10-29 21:14 ` Eli Schwartz @ 2021-10-29 21:28 ` Junio C Hamano 2021-10-29 21:44 ` Eli Schwartz 1 sibling, 1 reply; 46+ messages in thread From: Junio C Hamano @ 2021-10-29 21:28 UTC (permalink / raw) To: Eli Schwartz; +Cc: git 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. ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v3 2/3] pretty: add tag option to %(describe) 2021-10-29 21:28 ` Junio C Hamano @ 2021-10-29 21:44 ` Eli Schwartz 0 siblings, 0 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-29 21:44 UTC (permalink / raw) To: Junio C Hamano; +Cc: git [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v3 3/3] pretty: add abbrev option to %(describe) 2021-10-29 18:45 ` [PATCH v3 0/3] Add some more options to the pretty-formats Eli Schwartz 2021-10-29 18:45 ` [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz 2021-10-29 18:45 ` [PATCH v3 2/3] pretty: add tag option to %(describe) Eli Schwartz @ 2021-10-29 18:45 ` Eli Schwartz 2021-10-29 18:51 ` Eric Sunshine 2021-10-31 17:15 ` [PATCH v4 0/3] Add some more options to the pretty-formats Eli Schwartz 3 siblings, 1 reply; 46+ messages in thread From: Eli Schwartz @ 2021-10-29 18:45 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/3] pretty: add abbrev option to %(describe) 2021-10-29 18:45 ` [PATCH v3 3/3] pretty: add abbrev " Eli Schwartz @ 2021-10-29 18:51 ` Eric Sunshine 2021-10-29 19:04 ` Eli Schwartz 0 siblings, 1 reply; 46+ messages in thread From: Eric Sunshine @ 2021-10-29 18:51 UTC (permalink / raw) To: Eli Schwartz; +Cc: Git List 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? ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v3 3/3] pretty: add abbrev option to %(describe) 2021-10-29 18:51 ` Eric Sunshine @ 2021-10-29 19:04 ` Eli Schwartz 0 siblings, 0 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-29 19:04 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v4 0/3] Add some more options to the pretty-formats 2021-10-29 18:45 ` [PATCH v3 0/3] Add some more options to the pretty-formats Eli Schwartz ` (2 preceding siblings ...) 2021-10-29 18:45 ` [PATCH v3 3/3] pretty: add abbrev " Eli Schwartz @ 2021-10-31 17:15 ` Eli Schwartz 2021-10-31 17:15 ` [PATCH v4 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz ` (2 more replies) 3 siblings, 3 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-31 17:15 UTC (permalink / raw) To: git; +Cc: Junio C Hamano, Eric Sunshine 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v4 1/3] pretty.c: rework describe options parsing for better extensibility 2021-10-31 17:15 ` [PATCH v4 0/3] Add some more options to the pretty-formats Eli Schwartz @ 2021-10-31 17:15 ` Eli Schwartz 2021-10-31 17:15 ` [PATCH v4 2/3] pretty: add tag option to %(describe) Eli Schwartz 2021-10-31 17:15 ` [PATCH v4 3/3] pretty: add abbrev " Eli Schwartz 2 siblings, 0 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-31 17:15 UTC (permalink / raw) To: git; +Cc: Junio C Hamano, Eric Sunshine 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH v4 2/3] pretty: add tag option to %(describe) 2021-10-31 17:15 ` [PATCH v4 0/3] Add some more options to the pretty-formats Eli Schwartz 2021-10-31 17:15 ` [PATCH v4 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz @ 2021-10-31 17:15 ` Eli Schwartz 2021-10-31 18:07 ` Junio C Hamano 2021-10-31 17:15 ` [PATCH v4 3/3] pretty: add abbrev " Eli Schwartz 2 siblings, 1 reply; 46+ messages in thread From: Eli Schwartz @ 2021-10-31 17:15 UTC (permalink / raw) To: git; +Cc: Junio C Hamano, Eric Sunshine 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v4 2/3] pretty: add tag option to %(describe) 2021-10-31 17:15 ` [PATCH v4 2/3] pretty: add tag option to %(describe) Eli Schwartz @ 2021-10-31 18:07 ` Junio C Hamano 2021-10-31 18:58 ` Eli Schwartz 0 siblings, 1 reply; 46+ messages in thread From: Junio C Hamano @ 2021-10-31 18:07 UTC (permalink / raw) To: Eli Schwartz, Jean-Noël Avila; +Cc: git, Eric Sunshine, Martin Ågren 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] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v4 2/3] pretty: add tag option to %(describe) 2021-10-31 18:07 ` Junio C Hamano @ 2021-10-31 18:58 ` Eli Schwartz 0 siblings, 0 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-31 18:58 UTC (permalink / raw) To: Junio C Hamano, Jean-Noël Avila Cc: git, Eric Sunshine, Martin Ågren [-- 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 --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH v4 3/3] pretty: add abbrev option to %(describe) 2021-10-31 17:15 ` [PATCH v4 0/3] Add some more options to the pretty-formats Eli Schwartz 2021-10-31 17:15 ` [PATCH v4 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz 2021-10-31 17:15 ` [PATCH v4 2/3] pretty: add tag option to %(describe) Eli Schwartz @ 2021-10-31 17:15 ` Eli Schwartz 2 siblings, 0 replies; 46+ messages in thread From: Eli Schwartz @ 2021-10-31 17:15 UTC (permalink / raw) To: git; +Cc: Junio C Hamano, Eric Sunshine 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 ^ permalink raw reply related [flat|nested] 46+ messages in thread
end of thread, other threads:[~2021-11-07 12:40 UTC | newest] Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-24 1:42 [PATCH 0/3] Add some more options to the pretty-formats Eli Schwartz 2021-10-24 1:42 ` [PATCH 1/3] pretty.c: rename describe options variable to more descriptive name Eli Schwartz 2021-10-24 4:31 ` Junio C Hamano 2021-10-24 15:37 ` Eli Schwartz 2021-10-24 1:42 ` [PATCH 2/3] pretty: add tag option to %(describe) Eli Schwartz 2021-10-24 4:57 ` Junio C Hamano 2021-10-24 15:38 ` Eli Schwartz 2021-10-24 1:42 ` [PATCH 3/3] pretty: add abbrev " Eli Schwartz 2021-10-24 5:15 ` Junio C Hamano 2021-10-24 15:43 ` Eli Schwartz 2021-10-26 1:34 ` [PATCH v2 0/3] Add some more options to the pretty-formats Eli Schwartz 2021-10-26 1:34 ` [PATCH v2 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz 2021-10-26 5:18 ` Eric Sunshine 2021-10-26 20:05 ` Eli Schwartz 2021-10-26 1:34 ` [PATCH v2 2/3] pretty: add tag option to %(describe) Eli Schwartz 2021-10-26 5:25 ` Eric Sunshine 2021-10-26 20:06 ` Eli Schwartz 2021-10-26 1:34 ` [PATCH v2 3/3] pretty: add abbrev " Eli Schwartz 2021-10-26 5:36 ` Eric Sunshine 2021-10-26 12:06 ` Đoàn Trần Công Danh 2021-10-26 17:28 ` Eric Sunshine 2021-10-26 19:12 ` Eli Schwartz 2021-10-27 8:05 ` Carlo Arenas 2021-11-03 23:20 ` Johannes Schindelin 2021-11-04 9:29 ` Johannes Schindelin 2021-11-07 12:39 ` Eli Schwartz 2021-10-29 18:45 ` [PATCH v3 0/3] Add some more options to the pretty-formats Eli Schwartz 2021-10-29 18:45 ` [PATCH v3 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz 2021-10-29 20:11 ` Junio C Hamano 2021-10-29 21:06 ` Eli Schwartz 2021-10-29 21:34 ` Junio C Hamano 2021-10-29 18:45 ` [PATCH v3 2/3] pretty: add tag option to %(describe) Eli Schwartz 2021-10-29 20:18 ` Junio C Hamano 2021-10-29 21:14 ` Eli Schwartz 2021-10-29 21:46 ` Junio C Hamano 2021-10-29 21:28 ` Junio C Hamano 2021-10-29 21:44 ` Eli Schwartz 2021-10-29 18:45 ` [PATCH v3 3/3] pretty: add abbrev " Eli Schwartz 2021-10-29 18:51 ` Eric Sunshine 2021-10-29 19:04 ` Eli Schwartz 2021-10-31 17:15 ` [PATCH v4 0/3] Add some more options to the pretty-formats Eli Schwartz 2021-10-31 17:15 ` [PATCH v4 1/3] pretty.c: rework describe options parsing for better extensibility Eli Schwartz 2021-10-31 17:15 ` [PATCH v4 2/3] pretty: add tag option to %(describe) Eli Schwartz 2021-10-31 18:07 ` Junio C Hamano 2021-10-31 18:58 ` Eli Schwartz 2021-10-31 17:15 ` [PATCH v4 3/3] pretty: add abbrev " Eli Schwartz
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.