| Message ID | 20230828144940.18245-1-sir@cmpwn.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] builtin/log.c: prepend "RFC" on --rfc | expand |
Drew DeVault <sir@cmpwn.com> writes: > Rather than replacing the configured subject prefix (either through the > git config or command line) entirely with "RFC PATCH", this change > prepends RFC to whatever subject prefix was already in use. > > This is useful, for example, when a user is working on a repository that > has a subject prefix considered to disambiguate patches: > > git config format.subjectPrefix 'PATCH my-project' > > Prior to this change, formatting patches with --rfc would lose the > 'my-project' information. > > Signed-off-by: Drew DeVault <sir@cmpwn.com> > --- > v2 incorporates feedback from Jeff King regarding the lifetime of the > heap-allocated "RFC %s" formatted string. For future reference, you can signal that by adding Helped-by: Jeff King <peff@peff.net> before [*] your Sign-off. I'll do that on the receiving end so no need to resend this patch only to correct for this. Side note: in other words, in the chronological order of what happened to this particular version of the patch that you expect to hit my tree (you wrote this version with the help by peff, and after proofreading the end product certify that you are contributing to this project under DCO 1.1). > Documentation/git-format-patch.txt | 6 +++--- > builtin/log.c | 12 +++++++++++- > t/t4014-format-patch.sh | 9 +++++++++ > 3 files changed, 23 insertions(+), 4 deletions(-) > > diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt > index 373b46fc0d..fdc52cf826 100644 > --- a/Documentation/git-format-patch.txt > +++ b/Documentation/git-format-patch.txt > @@ -229,9 +229,9 @@ populated with placeholder text. > variable, or 64 if unconfigured. > > --rfc:: > - Alias for `--subject-prefix="RFC PATCH"`. RFC means "Request For > - Comments"; use this when sending an experimental patch for > - discussion rather than application. > + Prepends "RFC" to the subject prefix (producing "RFC PATCH" by > + default). RFC means "Request For Comments"; use this when sending > + an experimental patch for discussion rather than application. Looks good. Nowhere in the manual page we hint how the separation between "fairly permanent" customization with format.subjectPrefix and "per invocation" customization with this option, which has now become possible, is expected to be useful. Do we expect it is too obvious for our readers and they will figure it out themselves? It might be sufficient to add mention of format.subjectPrefix to the description of "--subject-prefix=<subject prefix>" option on the same page, with possible rephrasing of "useful naming of a patch series", which leans toward "per invocation" customization (i.e. even for the same project, different names may be used depending on a patch series). > diff --git a/builtin/log.c b/builtin/log.c > index db3a88bfe9..854216ee9c 100644 > --- a/builtin/log.c > +++ b/builtin/log.c > @@ -1476,9 +1476,19 @@ static int subject_prefix_callback(const struct option *opt, const char *arg, > > static int rfc_callback(const struct option *opt, const char *arg, int unset) > { > + /* > + * The subject_prefix in rev_info is not heap-allocated except in this > + * specific case, so there is no obvious place to free it. Since this > + * value is retained for the lifetime of the process, we just > + * statically allocate storage for it here. > + */ > + static char *prefix; > BUG_ON_OPT_NEG(unset); > BUG_ON_OPT_ARG(arg); > - return subject_prefix_callback(opt, "RFC PATCH", unset); > + > + free(prefix); > + prefix = xstrfmt("RFC %s", ((struct rev_info *)opt->value)->subject_prefix); > + return subject_prefix_callback(opt, prefix, unset); > } In the current code before this patch, the rev.subject_prefix member holds one of: * hardcoded "PATCH" in BSS (i.e. fmt_patch_subject_prefix) * hardcoded "RFC PATCH" in BSS when "--rfc" is given * value given to command line arg "--subject-prefix=<prefix>" * value given to format.subjectprefix and the last one should be freed. We are removing the second one and replacing it with whatever we will do when adding this feature so we should be able to make it freeable. And I do not think it is hard to make the third one freeable. I wonder how far we can go to plug this leak by simply - making subject_prefix_callback() xstrdup() its arg and free the current value, unless it is the same pointer as fmt_patch_subject_prefix, before assigning a new value, and - making "format.subjectprefix" take the value in a temporary variable from git_config_string(), call subject_prefix_callback(), and free that temporary. Then unless you use --rfc, --subject-prefix, or the format.subjectprefix variable, we will have no allocation, and if you use any of these, you'll allocate and do the right thing, no? Of course, as this is "we compute the value once and keep using it without reallocating or updating", coming up with overly complex solution is not worth it, so the "we only have one allocated string pointed at by a static, but repeated use of options will not leak" we see above is probably good enough. > +test_expect_success '--rfc does not overwrite prefix' ' > + cat >expect <<-\EOF && > + Subject: [RFC PATCH foobar 1/1] header with . in it > + EOF > + git format-patch -n -1 --stdout --subject-prefix "PATCH foobar" --rfc >patch && This is OK but it does not really test the expected use case, does it? Nobody sane would give both --subject-prefix and --rfc from the command line---they will do --subject-prefix="RFC PATCH foobar" instead, of course. git -c format.subjectPrefix="PATCH foobar" \ -n -1 --stdout --rfc >patch may be much closer to what we expect to see in the real life, I would think. > + grep ^Subject: patch >actual && While it is not wrong per se, let's quote the pattern. Visually, any token with a colon at the end attracts whatever comes after it and pulls the readers into an illusion that they are part of the same single command line argument. I.e. grep -e "^Subject: " patch >actual && Thanks. > + test_cmp expect actual > +' > + > test_expect_success '--from=ident notices bogus ident' ' > test_must_fail git format-patch -1 --stdout --from=foo >patch > '
On Mon, Aug 28, 2023 at 09:15:30AM -0700, Junio C Hamano wrote: > In the current code before this patch, the rev.subject_prefix member > holds one of: > > * hardcoded "PATCH" in BSS (i.e. fmt_patch_subject_prefix) > * hardcoded "RFC PATCH" in BSS when "--rfc" is given > * value given to command line arg "--subject-prefix=<prefix>" > * value given to format.subjectprefix > > and the last one should be freed. We are removing the second one > and replacing it with whatever we will do when adding this feature > so we should be able to make it freeable. And I do not think it is > hard to make the third one freeable. > > I wonder how far we can go to plug this leak by simply > > - making subject_prefix_callback() xstrdup() its arg and free the > current value, unless it is the same pointer as > fmt_patch_subject_prefix, before assigning a new value, and > > - making "format.subjectprefix" take the value in a temporary > variable from git_config_string(), call > subject_prefix_callback(), and free that temporary. I am not super familiar with this code, so could easily be missing something here, but I think that you can do this in a more direct way like so: --- 8< --- diff --git a/builtin/log.c b/builtin/log.c index 854216ee9c..f1c6c08f75 100644 --- a/builtin/log.c +++ b/builtin/log.c @@ -67,6 +67,7 @@ static const char *fmt_patch_subject_prefix = "PATCH"; static int fmt_patch_name_max = FORMAT_PATCH_NAME_MAX_DEFAULT; static const char *fmt_pretty; static int format_no_prefix; +static char *subject_prefix; static const char * const builtin_log_usage[] = { N_("git log [<options>] [<revision-range>] [[--] <path>...]"), @@ -362,6 +363,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix, static int cmd_log_deinit(int ret, struct rev_info *rev) { release_revisions(rev); + free(subject_prefix); return ret; } @@ -1463,32 +1465,27 @@ static int keep_callback(const struct option *opt, const char *arg, int unset) return 0; } -static int subject_prefix = 0; - static int subject_prefix_callback(const struct option *opt, const char *arg, int unset) { + struct rev_info *revs = opt->value; BUG_ON_OPT_NEG(unset); - subject_prefix = 1; - ((struct rev_info *)opt->value)->subject_prefix = arg; + + revs->subject_prefix = arg; + return 0; } static int rfc_callback(const struct option *opt, const char *arg, int unset) { - /* - * The subject_prefix in rev_info is not heap-allocated except in this - * specific case, so there is no obvious place to free it. Since this - * value is retained for the lifetime of the process, we just - * statically allocate storage for it here. - */ - static char *prefix; + struct rev_info *revs = opt->value; + BUG_ON_OPT_NEG(unset); BUG_ON_OPT_ARG(arg); - free(prefix); - prefix = xstrfmt("RFC %s", ((struct rev_info *)opt->value)->subject_prefix); - return subject_prefix_callback(opt, prefix, unset); + free(subject_prefix); + subject_prefix = xstrfmt("RFC %s", revs->subject_prefix); + return subject_prefix_callback(opt, subject_prefix, unset); } static int numbered_cmdline_opt = 0; --- >8 --- since we already have cmd_log_deinit(), which currently just calls `release_revisions()` and then propagates a return code. We can't foist freeing the subject_prefix into release_revisions, since (as noted above), sometimes the value will point into the program's BSS. But the only time we care about free()-ing subject_prefix is when we xstrdup() a new value into it, and the only place we do that is in rfc_callback(). Thanks, Taylor
Taylor Blau <me@ttaylorr.com> writes: > I am not super familiar with this code, so could easily be missing > something here, but I think that you can do this in a more direct way > like so: > ... > static int rfc_callback(const struct option *opt, const char *arg, int unset) > { > + free(subject_prefix); > + subject_prefix = xstrfmt("RFC %s", revs->subject_prefix); As Phillip Wood pointed out, this approach no longer works once "--rfc" is "no matter what subject-prefix says, we prepend RFC in front", as the order of command line flags is not forced. At this point, revs->subject_prefix may be one value (or worse, even not initialized), and then --subject-prefix=<new-prefix> command line argument may yet to be parsed. > + return subject_prefix_callback(opt, subject_prefix, unset); > } So, we'd most likely need to treat subject_prefix and rfc as two separate strings while parse_options() is doing its work, and then after that prepend the rfc string, if set, to the final version of the subject_prefix string.
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 373b46fc0d..fdc52cf826 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -229,9 +229,9 @@ populated with placeholder text. variable, or 64 if unconfigured. --rfc:: - Alias for `--subject-prefix="RFC PATCH"`. RFC means "Request For - Comments"; use this when sending an experimental patch for - discussion rather than application. + Prepends "RFC" to the subject prefix (producing "RFC PATCH" by + default). RFC means "Request For Comments"; use this when sending + an experimental patch for discussion rather than application. -v <n>:: --reroll-count=<n>:: diff --git a/builtin/log.c b/builtin/log.c index db3a88bfe9..854216ee9c 100644 --- a/builtin/log.c +++ b/builtin/log.c @@ -1476,9 +1476,19 @@ static int subject_prefix_callback(const struct option *opt, const char *arg, static int rfc_callback(const struct option *opt, const char *arg, int unset) { + /* + * The subject_prefix in rev_info is not heap-allocated except in this + * specific case, so there is no obvious place to free it. Since this + * value is retained for the lifetime of the process, we just + * statically allocate storage for it here. + */ + static char *prefix; BUG_ON_OPT_NEG(unset); BUG_ON_OPT_ARG(arg); - return subject_prefix_callback(opt, "RFC PATCH", unset); + + free(prefix); + prefix = xstrfmt("RFC %s", ((struct rev_info *)opt->value)->subject_prefix); + return subject_prefix_callback(opt, prefix, unset); } static int numbered_cmdline_opt = 0; diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh index 3cf2b7a7fb..a7fe839683 100755 --- a/t/t4014-format-patch.sh +++ b/t/t4014-format-patch.sh @@ -1377,6 +1377,15 @@ test_expect_success '--rfc' ' test_cmp expect actual ' +test_expect_success '--rfc does not overwrite prefix' ' + cat >expect <<-\EOF && + Subject: [RFC PATCH foobar 1/1] header with . in it + EOF + git format-patch -n -1 --stdout --subject-prefix "PATCH foobar" --rfc >patch && + grep ^Subject: patch >actual && + test_cmp expect actual +' + test_expect_success '--from=ident notices bogus ident' ' test_must_fail git format-patch -1 --stdout --from=foo >patch '
Rather than replacing the configured subject prefix (either through the git config or command line) entirely with "RFC PATCH", this change prepends RFC to whatever subject prefix was already in use. This is useful, for example, when a user is working on a repository that has a subject prefix considered to disambiguate patches: git config format.subjectPrefix 'PATCH my-project' Prior to this change, formatting patches with --rfc would lose the 'my-project' information. Signed-off-by: Drew DeVault <sir@cmpwn.com> --- v2 incorporates feedback from Jeff King regarding the lifetime of the heap-allocated "RFC %s" formatted string. Documentation/git-format-patch.txt | 6 +++--- builtin/log.c | 12 +++++++++++- t/t4014-format-patch.sh | 9 +++++++++ 3 files changed, 23 insertions(+), 4 deletions(-)