* [PATCH v2] builtin/log.c: prepend "RFC" on --rfc
@ 2023-08-28 14:48 Drew DeVault
2023-08-28 16:15 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Drew DeVault @ 2023-08-28 14:48 UTC (permalink / raw
To: git; +Cc: Drew DeVault
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(-)
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
'
--
2.42.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2] builtin/log.c: prepend "RFC" on --rfc
2023-08-28 14:48 [PATCH v2] builtin/log.c: prepend "RFC" on --rfc Drew DeVault
@ 2023-08-28 16:15 ` Junio C Hamano
2023-08-28 23:21 ` Taylor Blau
0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2023-08-28 16:15 UTC (permalink / raw
To: Drew DeVault; +Cc: git
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
> '
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] builtin/log.c: prepend "RFC" on --rfc
2023-08-28 16:15 ` Junio C Hamano
@ 2023-08-28 23:21 ` Taylor Blau
2023-08-28 23:53 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Taylor Blau @ 2023-08-28 23:21 UTC (permalink / raw
To: Junio C Hamano; +Cc: Drew DeVault, git
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
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2] builtin/log.c: prepend "RFC" on --rfc
2023-08-28 23:21 ` Taylor Blau
@ 2023-08-28 23:53 ` Junio C Hamano
0 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2023-08-28 23:53 UTC (permalink / raw
To: Taylor Blau; +Cc: Drew DeVault, git
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-08-28 23:54 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-08-28 14:48 [PATCH v2] builtin/log.c: prepend "RFC" on --rfc Drew DeVault
2023-08-28 16:15 ` Junio C Hamano
2023-08-28 23:21 ` Taylor Blau
2023-08-28 23:53 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).