format-patch: handle range-diff on notes correctly for single patches
cover format-patch: handle range-diff on notes correctly for single patches
From: Kristoffer Haugsbakk <[email protected]>
git-format-patch(1) does not handle Git notes correctly in the range-diff output for single-commit series. It reverts to the default behavior of git-range-diff(1), which is to act like git-log(1).
Fix that notes handling to always output the same notes (namespaces) in the two positions:
• beneath the commit message; and
• in the range-diff.
Do that by (patch by patch):
1. Refactoring to use a new ref_info struct member
2. Using that in log-tree.c
§ Testing
I have (for once) tried to check for leaks by running the test suite with this config.mak:
``` DEVELOPER=1 DEBUG=1 CC = ccache gcc CFLAGS+=-O0 CFLAGS+=-ggdb3 USE_ASCIIDOCTOR=true SANITIZE=leak,address ```
Kristoffer Haugsbakk (2):
revision: add rdiff_other_arg to rev_info
format-patch: handle range-diff on notes correctly for single patches
builtin/log.c | 7 +++---- log-tree.c | 3 ++- revision.h | 1 + t/t3206-range-diff.sh | 16 +++++++++++++++- 4 files changed, 21 insertions(+), 6 deletions(-)
base-commit: ca2559c1d630eb4f04cdee2328aaf1c768907a9e
Signature · 1 line
2.51.0.270.gdb73cbc1bc1
PATCH 1/2 revision: add rdiff_other_arg to rev_info
From: Kristoffer Haugsbakk <[email protected]>
git-format-patch(1) needs to pass --[no-]notes options on to the range-diff subprocess in range-diff.c. This is handled in builtin/ log.c by the local variable other_arg in the case of multiple commits, but not in the single commit case where there is no cover letter and the range-diff is on that single resulting patch; the range-diff is then made in log-tree.c, whither other_arg has not been propagated.
git-format-patch(1) is supposed to treat Git notes the same between notes output beneath the commit message and the notes output for the range-diff. But this lack of notes handling in log-tree.c breaks that expected behavior; range-diff notes handling for a single patch acts like a normal git-range-diff(1) invocation with regards to notes. You can, for example, end up with a patch where the note beneath the commit message has the correct notes namespace, but the range-diff has all the notes that are configured to be displayed by git-log(1).[1]
We need to fix this. But first lay the groundwork by converting other_arg to a struct member; next we can simply use that member in log-tree.c without having to thread it from builtin/log.c.
No functional changes.
† 1: See the configuration variable format.notes for git-format-
patch(1); c.f. notes.displayRef for git-log(1). These two have nothing to do with each other.
---
Notes (series):
There is also other_arg in builtin/range-diff.c but rev_info does not seem to be involved.
builtin/log.c | 7 +++---- revision.h | 1 + 2 files changed, 4 insertions(+), 4 deletions(-)
builtin/log.c +3 -4
@@ -1400,13 +1400,12 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file,* can be added later if deemed desirable. */ struct diff_options opts; -struct strvec other_arg =STRVEC_INIT ;struct range_diff_options range_diff_opts = { .creation_factor = rev->creation_factor, .dual_color =1 , .max_memory =RANGE_DIFF_MAX_MEMORY_DEFAULT , .diffopt = &opts, - .other_arg = &other_arg + .other_arg = &rev->rdiff_other_arg };repo_diff_setup (the_repository, &opts);
@@ -1414,9 +1413,7 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file, opts.use_color = rev->diffopt.use_color;diff_setup_done (&opts);fprintf_ln (rev->diffopt.file,"%s" , rev->rdiff_title); -get_notes_args (&other_arg, rev);show_range_diff (rev->rdiff1, rev->rdiff2, &range_diff_opts); -strvec_clear (&other_arg); } }
@@ -2328,6 +2325,7 @@ int cmd_format_patch(int argc, rev.rdiff_title =diff_title (&rdiff_title, reroll_count,_ ("Range-diff:" ),_ ("Range-diff against v%d:" )); +get_notes_args (&(rev.rdiff_other_arg), &rev); }/*
@@ -2487,6 +2485,7 @@ int cmd_format_patch(int argc, rev.diffopt.no_free =0 ;release_revisions (&rev);format_config_release (&cfg); +strvec_clear (&rev.rdiff_other_arg);return 0 ; }
revision.h +1 -0
@@ -334,6 +334,7 @@ struct rev_info {/* range-diff */ const char *rdiff1;const char *rdiff2; +struct strvec rdiff_other_arg;int creation_factor;const char *rdiff_title;
Signature · 1 line
2.51.0.270.gdb73cbc1bc1
Re: [PATCH 1/2] revision: add rdiff_other_arg to rev_info
Quoted 3 lines · [email protected] writes:
git-format-patch(1) is supposed to treat Git notes the same between notes output beneath the commit message and the notes output for the range-diff.
Is this an opinion, or are there things that existing pieces of code already do to achieve such a behaviour already?
revision.h struct rev_info { · line 339
Quoted 11 lines
revision.h +1
-0@@ -334,6 +334,7 @@ struct rev_info {/* range-diff */ const char *rdiff1;const char *rdiff2; +struct strvec rdiff_other_arg;int creation_factor;const char *rdiff_title;
When embedding a struct A in a struct B, we should always make sure that initialization macro/function for struct B is updated so that the initialization for struct A is done correctly for the new member.
We do have REV_INFO_INIT for "struct rev_info"
#define REV_INFO_INIT { \
.abbrev = DEFAULT_ABBREV, \
.simplify_history = 1, \
.pruning.flags.recursive = 1, \
...
.expand_tabs_in_log_default = 8, \
}that does not allow any existing callers to leave it uninitialized or get away by zero-initializing, so all the users must be using it or the system before your patch is already buggy.
And we do have STRVEC_INIT that we must use in that initializer.
extern const char *empty_strvec[];
struct strvec {
const char **v;
size_t nr;
size_t alloc;
};
#define STRVEC_INIT { \
.v = empty_strvec, \
}So this step forgets to update revision.h to teach STRVEC_INIT on the new rdiff_other_arg member.
Back when it was a random one-shot variable in range-diff, it might not have mattered all that much, but now we have it as a proper member of the struct, can we give it a name better than 'other_arg"? Or is it the case that truly any random crap can be slurped into the array and thrown back at "git log" without range-diff machinery understanding what it is doing at all (which I would not be surprised, as some parts of our code base is written in somewhat a sloppy way)?
Thanks.
Re: [PATCH 1/2] revision: add rdiff_other_arg to rev_info
Quoted 8 lines · Junio C Hamano
Quoted 3 lines · [email protected] writes:
git-format-patch(1) is supposed to treat Git notes the same between notes output beneath the commit message and the notes output for the range-diff.
Is this an opinion, or are there things that existing pieces of code already do to achieve such a behaviour already?
What I mean is that
Notes (...)
Beneath the commit message and
### Notes (...) ###
In the range-diff should be from the same namespaces. It shouldn’t be, for example:
Notes (presentation):
Beneath the commit message while the range-diff has:
### Notes (testing) ###
...
### Notes (scratchpad) ###That’s the point of passing --notes to range-diff.
Am I missing something in the explanation? The commit message might need a rewrite.
Quoted 44 lines
revision.h struct rev_info { · line 339
Quoted 11 lines
revision.h +1
-0@@ -334,6 +334,7 @@ struct rev_info {/* range-diff */ const char *rdiff1;const char *rdiff2; +struct strvec rdiff_other_arg;int creation_factor;const char *rdiff_title;When embedding a struct A in a struct B, we should always make sure that initialization macro/function for struct B is updated so that the initialization for struct A is done correctly for the new member.
We do have
REV_INFO_INITfor "structrev_info"#define REV_INFO_INIT { \ .abbrev = DEFAULT_ABBREV, \ .simplify_history = 1, \ .pruning.flags.recursive = 1, \ ... .expand_tabs_in_log_default = 8, \ }that does not allow any existing callers to leave it uninitialized or get away by zero-initializing, so all the users must be using it or the system before your patch is already buggy.
And we do have
STRVEC_INITthat we must use in that initializer.extern const char *empty_strvec[]; struct strvec { const char **v; size_t nr; size_t alloc; }; #define STRVEC_INIT { \ .v = empty_strvec, \ }
Quoted 2 lines
So this step forgets to update
revision.hto teachSTRVEC_INITon the newrdiff_other_argmember.
Thanks for the explanation. I’ve added .rdiff_other_arg = STRVEC_INIT \ to REV_INFO_INIT.
Quoted 3 lines
Back when it was a random one-shot variable in range-diff, it might not have mattered all that much, but now we have it as a proper member of the struct, can we give it a name better than '
other_arg"?
I’ve had that thought too. But then I forgot what a better name would be.
Could it be as simple as log_arg or log_args?
(This could be added as a preliminary patch)
builtin/range-diff.c uses range_diff_options.other_arg to pass --notes but also (and quite recently[1]) to pass --merges.
/* If `--diff-merges` was specified, imply `--merges` */
† 1: f8043236 (range-diff: optionally include merge commits' diffs in
the analysis, 2024-12-16)
Quoted 5 lines
Or is it the case that truly any random crap can be slurped into the array and thrown back at "git log" without range-diff machinery understanding what it is doing at all (which I would not be surprised, as some parts of our code base is written in somewhat a sloppy way)?
Well anything you throw into it will ultimately end up in the git-log(1) child process in range-diff.c:73.[2] But this doesn’t seem like a problem given that all the arguments are “programmed” as constant strings?
† 2: on ca2559c1 (The tenth batch, 2025-09-18)
Re: [PATCH 1/2] revision: add rdiff_other_arg to rev_info
Quoted 23 lines · Kristoffer Haugsbakk
Quoted 8 lines · Junio C Hamano
Quoted 3 lines · [email protected] writes:
git-format-patch(1) is supposed to treat Git notes the same between notes output beneath the commit message and the notes output for the range-diff.
Is this an opinion, or are there things that existing pieces of code already do to achieve such a behaviour already?
What I mean is that
Notes (...)Beneath the commit message and
### Notes (...) ###In the range-diff should be from the same namespaces. It shouldn’t be, for example:
Notes (presentation):
Quoted 7 lines
Beneath the commit message while the range-diff has:
### Notes (testing) ### ... ### Notes (scratchpad) ###That’s the point of passing
--notesto range-diff.
OK. So it is more like "range-diff is supposed to show comparison of pairs of patches; if format-patch shows one set of notes after three-dash lines in its output, range-diff invoked by format-patch to compare its patches with another set of patches should also be comparing patches generated with the same set of notes". That makes sense to me.
Quoted 2 lines
Thanks for the explanation. I’ve added
.rdiff_other_arg = STRVEC_INIT \toREV_INFO_INIT.
Yup, I think I already have a fix-up patch mixed in your series in the integration result I pushed out last night.
Quoted 1 line
Could it be as simple as
log_argorlog_args?
Yeah, that is much better than "other" (where it is unclear what are the "primary" things that "others" are in contrast).
Thanks.
Re: [PATCH 1/2] revision: add rdiff_other_arg to rev_info
Quoted 16 lines · Junio C Hamano
Quoted 7 lines · Kristoffer Haugsbakk
Quoted 6 lines · Junio C Hamano
Quoted 3 lines · [email protected] writes:
git-format-patch(1) is supposed to treat Git notes the same between notes output beneath the commit message and the notes output for the range-diff.
Quoted 6 lines
Quoted 2 lines
Is this an opinion, or are there things that existing pieces of code already do to achieve such a behaviour already?
What I mean is that
[snip]
That’s the point of passing--notesto range-diff.
Quoted 6 lines
OK. So it is more like "range-diff is supposed to show comparison of pairs of patches; if format-patch shows one set of notes after three-dash lines in its output, range-diff invoked by format-patch to compare its patches with another set of patches should also be comparing patches generated with the same set of notes". That makes sense to me.
Exactly.
I might eventually send some drafts of better commit messages.
Quoted 5 lines
Quoted 2 lines
Thanks for the explanation. I’ve added
.rdiff_other_arg = STRVEC_INIT \toREV_INFO_INIT.Yup, I think I already have a fix-up patch mixed in your series in the integration result I pushed out last night.
Oh yeah I saw that afterwards. Which made me spot a mistake in my own fixup... which was instructive. ;)
Quoted 4 lines
Quoted 1 line
Could it be as simple as
log_argorlog_args?Yeah, that is much better than "other" (where it is unclear what are the "primary" things that "others" are in contrast).
I remember looking at the code and having that realization: Oh, *other* is *log*. Huh.
... Maybe specifically log_args since it’s a strvec? git grep 'struct strvec' seems to give me a lot of plural (style).
Re: [PATCH 1/2] revision: add rdiff_other_arg to rev_info
Quoted 10 lines · Kristoffer Haugsbakk
Quoted 4 lines
Quoted 1 line
Could it be as simple as
log_argorlog_args?Yeah, that is much better than "other" (where it is unclear what are the "primary" things that "others" are in contrast).
I remember looking at the code and having that realization: Oh, *other* is *log*. Huh.
... Maybe specifically
log_argssince it’s astrvec?git grep 'struct strvec'seems to give me a lot of plural (style).
If you were asking me about singular vs plural, sorry, I didn't even realize that was the quesiton being asked.
My personal preference is to name arrays singular so that you can name its 0th element by saying dog[0], not dogs[0]. "dog[1] and dog[2] are friends" not dogs[1] and dogs[2]. An exception is when most of the time you use the array as a single unit as a collection, passing it around in the call chain, rarely addressing each individual element. I am OK to see such an array called plural (but of course, singular names are always fine)..
An instance of "struct strvec" may fall into the same category as the latter. A single "struct strvec args" may be used as a collection of arguments passed to the program .
So, log_args is fine by me.
PATCH 2/2 format-patch: handle range-diff on notes correctly for single patches
In reply to [email protected]From: Kristoffer Haugsbakk <[email protected]>
No --[no-]notes options are sent to the range-diff subprocess in range-diff.c when making a single patch. This means that you can get different Git notes below the commit message and in the range-diff part. (See the previous commit for elaboration.)
Use the struct member that we introduced and populated in the previous commit.
---
Notes (series):
I’ve tried to conform to 6caa96c2 (t3206: test_when_finished before dirtying operations, not after, 2024-08-06) in the test here.
log-tree.c | 3 ++- t/t3206-range-diff.sh | 16 +++++++++++++++- 2 files changed, 17 insertions(+), 2 deletions(-)
log-tree.c +2 -1
@@ -718,7 +718,8 @@ static void show_diff_of_diff(struct rev_info *opt) .creation_factor = opt->creation_factor, .dual_color = 1, .max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT, - .diffopt = &opts + .diffopt = &opts, + .other_arg = &opt->rdiff_other_arg };memcpy (&dq, &diff_queued_diff,sizeof (diff_queued_diff));
t/t3206-range-diff.sh +15 -1
@@ -707,7 +707,7 @@ test_expect_success 'format-patch --range-diff does not compare notes by default ! grep "note" 0000-* ' -test_expect_success 'format-patch --notes=custom --range-diff only compares custom notes' ' +test_expect_success 'format-patch --notes=custom --range-diff --cover-letter only compares custom notes' ' test_when_finished "git notes remove topic unmodified || :" && git notes add -m "topic note" topic && git notes add -m "unmodified note" unmodified &&
@@ -721,6 +721,20 @@ test_expect_success 'format-patch --notes=custom --range-diff only compares cust ! grep "## Notes ##" 0000-* ' +# --range-diff on a single commit requires --no-cover-letter +test_expect_success 'format-patch --notes=custom --range-diff on single commit only compares custom notes' ' + test_when_finished "git notes remove HEAD unmodified || :" && + git notes add -m "topic note" HEAD && + test_when_finished "git notes --ref=custom remove HEAD unmodified || :" && + git notes add -m "unmodified note" unmodified && + git notes --ref=custom add -m "topic note (custom)" HEAD && + git notes --ref=custom add -m "unmodified note (custom)" unmodified && + git format-patch --notes=custom --range-diff=$prev \ + -1 --stdout >actual && + test_grep "## Notes (custom) ##" actual && + test_grep ! "## Notes ##" actual +' + test_expect_success 'format-patch --range-diff with --no-notes' ' test_when_finished "git notes remove topic unmodified || :" && git notes add -m "topic note" topic &&
Signature · 1 line
2.51.0.270.gdb73cbc1bc1
Quoted 6 lines · [email protected] writes:
From: Kristoffer Haugsbakk <[email protected]>
No
--[no-]notesoptions are sent to the range-diff subprocess inrange-diff.cwhen making a single patch. This means that you can get different Git notes below the commit message and in the range-diff part. (See the previous commit for elaboration.)
Would this also mean "range-diff --no-notes" would not have any effect in squelching the note output in such a mode? If so, perhaps we should say not just "can get different Git notes" but "can get notes even when you asked not to"?
Quoted 30 lines
log-tree.c +2
-1@@ -718,7 +718,8 @@ static void show_diff_of_diff(struct rev_info *opt) .creation_factor = opt->creation_factor, .dual_color = 1, .max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT, - .diffopt = &opts + .diffopt = &opts, + .other_arg = &opt->rdiff_other_arg };memcpy (&dq, &diff_queued_diff,sizeof (diff_queued_diff));t/t3206-range-diff.sh +4
-1@@ -707,7 +707,7 @@ test_expect_success 'format-patch --range-diff does not compare notes by default ! grep "note" 0000-* ' -test_expect_success 'format-patch --notes=custom --range-diff only compares custom notes' ' +test_expect_success 'format-patch --notes=custom --range-diff --cover-letter only compares custom notes' ' test_when_finished "git notes remove topic unmodified || :" && git notes add -m "topic note" topic && git notes add -m "unmodified note" unmodified &&@@ -721,6 +721,20 @@ test_expect_success 'format-patch --notes=custom --range-diff only compares cust ! grep "## Notes ##" 0000-* ' +# --range-diff on a single commit requires --no-cover-letter +test_expect_success 'format-patch --notes=custom --range-diff on single commit only compares custom notes' ' + test_when_finished "git notes remove HEAD unmodified || :" &&
t/t3206-range-diff.sh test_expect_success 'format-patch --notes=custom --range-diff only compares cust · line 736
Quoted 10 lines
t/t3206-range-diff.sh +10
-0+ git notes add -m "topic note" HEAD && + test_when_finished "git notes --ref=custom remove HEAD unmodified || :" && + git notes add -m "unmodified note" unmodified && + git notes --ref=custom add -m "topic note (custom)" HEAD && + git notes --ref=custom add -m "unmodified note (custom)" unmodified && + git format-patch --notes=custom --range-diff=$prev \ + -1 --stdout >actual && + test_grep "## Notes (custom) ##" actual && + test_grep ! "## Notes ##" actual +'
Sounds sensible.
Quoted 3 lines
t/t3206-range-diff.sh +0
-0test_expect_success 'format-patch --range-diff with --no-notes' ' test_when_finished "git notes remove topic unmodified || :" && git notes add -m "topic note" topic &&
Quoted 11 lines · Junio C Hamano
Quoted 6 lines · [email protected] writes:
From: Kristoffer Haugsbakk <[email protected]>
No
--[no-]notesoptions are sent to the range-diff subprocess inrange-diff.cwhen making a single patch. This means that you can get different Git notes below the commit message and in the range-diff part. (See the previous commit for elaboration.)Would this also mean "range-diff --no-notes" would not have any effect in squelching the note output in such a mode?
Do you mean git format-patch ... --range-diff --no-notes? Yes, --no-notes has no effect. range-diff just does the default thing which is --show-notes-by-default (act like git-log(1), which shows the default notes namespace unless any --[no-]notes options are given (and there are no such options in this case)).
Quoted 2 lines
If so, perhaps we should say not just "can get different Git notes" but "can get notes even when you asked not to"?
I think “can get different Git notes” covers all possibilities, both too many and too few.
But like the previous commit this one could maybe use a rewrite.
No --[no-]--notes options are sent to the range-diff subprocess in range-diff.c when making a single patch. This means that range-diff will handle Git notes like git-log(1).
This is a problem when you ask to use certain notes, or none at all, since that set of notes will appear beneath the commit message but the range-diff will have whatever notes that git-log(1) would have given you.
That’s at least less dense.
Quoted 2 lines
Quoted 2 lines
(quoted diff) +0
-0@@ -718,7 +718,8 @@ static void show_diff_of_diff(struct rev_info *opt)
Quoted 10 lines · Kristoffer Haugsbakk
Quoted 9 lines · Junio C Hamano
Quoted 6 lines · [email protected] writes:
From: Kristoffer Haugsbakk <[email protected]>
No
--[no-]notesoptions are sent to the range-diff subprocess inrange-diff.cwhen making a single patch. This means that you can get different Git notes below the commit message and in the range-diff part. (See the previous commit for elaboration.)
Quoted 8 lines
Quoted 2 lines
Would this also mean "range-diff --no-notes" would not have any effect in squelching the note output in such a mode?
Do you mean
git format-patch ... --range-diff --no-notes? Yes,--no-noteshas no effect. range-diff just does the default thing which is--show-notes-by-default(act like git-log(1), which shows the default notes namespace unless any--[no-]notesoptions are given (and there are no such options in this case)).
And this change will fix that too, which is nice.
Quoted 3 lines
But like the previous commit this one could maybe use a rewrite.
No
--[no-]--notesoptions are sent to the range-diff subprocess in
"--notes" --> "notes", as a required single dash after negation is already inside [] ;-)
Quoted 9 lines
range-diff.cwhen making a single patch. This means that range-diff will handle Git notes like git-log(1).This is a problem when you ask to use certain notes, or none at all, since that set of notes will appear beneath the commit message but the range-diff will have whatever notes that git-log(1) would have given you.
That’s at least less dense.
Thanks.
v2 cover format-patch: handle range-diff on notes correctly for single patches
In reply to [email protected]From: Kristoffer Haugsbakk <[email protected]>
git-format-patch(1) does not handle Git notes correctly in the range-diff output for single-commit series. It reverts to the default behavior of git-range-diff(1), which is to act like git-log(1).
Git notes can be added to patches where they go beneath the commit message (similar to git-log(1)). You can of course use any set of notes ref names. And the range-diff is supposed to use the same ref names. This works for the case when you have a cover letter (for more than one commit) but not when you have a single commit.
See patch 2/3 for a full explanation of the problem.
Fix that notes handling to always output the same notes (ref names) in the two positions:
• beneath the commit message; and
• in the range diff.
Patch-by-patch:
1. Rename other_arg to log_arg
2. Refactor to use a new rev_info struct member
3. Use that in log-tree.c in order to solve the problem
§ Changes in v2
Mostly better commit messages. Fix a mistake in the rev_info struct handling.
Patch-by-patch (see notes on them for details):
1. (new) Better variable name
2. Rewrite commit message and fix mistake
3. Rewrite commit message by mostly stealing from patch 2/3
About the commit messages: the first one just jumped into the problem without a proper introduction (see the note on patch 2/3). Not clear enough. But I didn’t act on this review feedback:[1]
“ Would this also mean "range-diff --no-notes" would not have any
effect in squelching the note output in such a mode? If so, perhaps we should say not just "can get different Git notes" but "can get notes even when you asked not to"?
🔗 1: https://lore.kernel.org/git/[email protected]/
Since both commits in v1 already said --[no-]notes.
§ CC
Denton Liu wrote a commit mentioned in patch 1/3. It’s been more years than the recommended cutoff, but he has been active recently.
§ Link to the previous version
https://lore.kernel.org/git/[email protected]/
❦ ❦ ❦ ❦ ❦
(this means you can skip to the diffs)
§ How I Present Patch Series
Version: 1
The cover letter:
• Problem statement and solution
• (optional) Summary of what each commit/patch does
• Changes compared to the previous version
• Note that all versions are not included
• (optional) “CC”/“Cc” which explains all or parts of the CC list
• But some things are not noteworthy, like the standard practice of including previous-round respondents
• Link to the previous version
• This is new. I thought it was redundant but some people (like me!) use webapp email clients which are not that great for navigating among tree-like email threads. So I was inspired by this practice which many others already use.
• I like including an interdiff in addition to the range diff if I can. They are just so convenient and complementary to the range diff.
Then each commit/patch might have Git notes with a series namespace (ref name) These contain:
• Comments/questions to reviewers about my approach or statements made in the commit message.
• Lines starting with v<version>: which introduce a changelog for that version. Lately (Sep 2025) these have been written in the “imperative mood”, like what is done for a commit message in this (Git) project. A bit strange, given that most others seem to use the more immediately natural past-tense. But on the other hand: how many new contributors to this project use the wrong tense/mood in their commit messages? The Git project rule is not “natural”. But I think it’s better nonetheless and worth the effort.
(And it might be worth the effort in this context, too. We will see.)
• ... But this kind of changelog might also be conducive to a bullet list of changes. So I might either skip the previous point, do only a bullet point, or do both: a presentation and then the bullet points summarizing the presentation.
• Note that all v<version>: are kept between versions, which is not consistent with how I only have the “Changes” part for the previous version.
• v<version>: are ordered newest-to-oldest.
Kristoffer Haugsbakk (3):
range-diff: rename other_arg to log_arg
revision: add rdiff_log_arg to rev_info
format-patch: handle range-diff on notes correctly for single patches
builtin/log.c | 7 +++---- builtin/range-diff.c | 16 ++++++++-------- log-tree.c | 3 ++- range-diff.c | 10 +++++----- range-diff.h | 2 +- revision.h | 2 ++ t/t3206-range-diff.sh | 16 +++++++++++++++- 7 files changed, 36 insertions(+), 20 deletions(-)
Interdiff against v1:
builtin/log.c +3 -3
@@ -1405,7 +1405,7 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file, .dual_color = 1, .max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT, .diffopt = &opts, - .other_arg = &rev->rdiff_other_arg + .log_arg = &rev->rdiff_log_arg };repo_diff_setup (the_repository, &opts);
@@ -2325,7 +2325,7 @@ int cmd_format_patch(int argc, rev.rdiff_title =diff_title (&rdiff_title, reroll_count,_ ("Range-diff:" ),_ ("Range-diff against v%d:" )); -get_notes_args (&(rev.rdiff_other_arg), &rev); +get_notes_args (&(rev.rdiff_log_arg), &rev); }/*
@@ -2485,7 +2485,7 @@ int cmd_format_patch(int argc, rev.diffopt.no_free =0 ;release_revisions (&rev);format_config_release (&cfg); -strvec_clear (&rev.rdiff_other_arg); +strvec_clear (&rev.rdiff_log_arg);return 0 ; }
builtin/range-diff.c +8 -8
@@ -37,13 +37,13 @@ int cmd_range_diff(int argc, struct repository *repo UNUSED) {struct diff_options diffopt = {NULL }; -struct strvec other_arg =STRVEC_INIT ; +struct strvec log_arg =STRVEC_INIT ;struct strvec diff_merges_arg =STRVEC_INIT ;struct range_diff_options range_diff_opts = { .creation_factor =RANGE_DIFF_CREATION_FACTOR_DEFAULT , .max_memory =RANGE_DIFF_MAX_MEMORY_DEFAULT , .diffopt = &diffopt, - .other_arg = &other_arg + .log_arg = &log_arg };int simple_color =-1 , left_only =0 , right_only =0 ;struct option range_diff_options[] = {
@@ -52,7 +52,7 @@ int cmd_range_diff(int argc, N_("percentage by which creation is weighted")),OPT_BOOL (0 ,"no-dual-color" , &simple_color,N_ ("use simple diff colors" )), -OPT_PASSTHRU_ARGV (0 ,"notes" , &other_arg, +OPT_PASSTHRU_ARGV (0 ,"notes" , &log_arg,N_ ("notes" ),N_ ("passed to 'git log'" ),PARSE_OPT_OPTARG ), OPT_PASSTHRU_ARGV(0, "diff-merges", &diff_merges_arg,
@@ -92,7 +92,7 @@ int cmd_range_diff(int argc,/* If `--diff-merges` was specified, imply `--merges` */ if (diff_merges_arg.nr) { range_diff_opts.include_merges =1 ; -strvec_pushv (&other_arg, diff_merges_arg.v); +strvec_pushv (&log_arg, diff_merges_arg.v); }for (i =0 ; i < argc; i++)
@@ -124,7 +124,7 @@ int cmd_range_diff(int argc,strbuf_addf (&range1,"%s..%s" , argv[0 ], argv[1 ]);strbuf_addf (&range2,"%s..%s" , argv[0 ], argv[2 ]); -strvec_pushv (&other_arg, argv + +strvec_pushv (&log_arg, argv + (dash_dash <0 ?3 : dash_dash)); } else if (dash_dash == 2 || (dash_dash < 0 && argc > 1 &&
@@ -144,7 +144,7 @@ int cmd_range_diff(int argc,strbuf_addstr (&range1, argv[0 ]);strbuf_addstr (&range2, argv[1 ]); -strvec_pushv (&other_arg, argv + +strvec_pushv (&log_arg, argv + (dash_dash <0 ?2 : dash_dash)); } else if (dash_dash == 1 || (dash_dash < 0 && argc > 0 &&
@@ -175,7 +175,7 @@ int cmd_range_diff(int argc,strbuf_addf (&range1,"%s..%.*s" , b, a_len, a);strbuf_addf (&range2,"%.*s..%s" , a_len, a, b); -strvec_pushv (&other_arg, argv + +strvec_pushv (&log_arg, argv + (dash_dash <0 ?1 : dash_dash)); }else usage_msg_opt(_("need two commit ranges"),
@@ -187,7 +187,7 @@ int cmd_range_diff(int argc, range_diff_opts.right_only = right_only; res =show_range_diff (range1.buf, range2.buf, &range_diff_opts); -strvec_clear (&other_arg); +strvec_clear (&log_arg);strvec_clear (&diff_merges_arg);strbuf_release (&range1);strbuf_release (&range2);
log-tree.c +1 -1
@@ -719,7 +719,7 @@ static void show_diff_of_diff(struct rev_info *opt) .dual_color = 1, .max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT, .diffopt = &opts, - .other_arg = &opt->rdiff_other_arg + .log_arg = &opt->rdiff_log_arg };memcpy (&dq, &diff_queued_diff,sizeof (diff_queued_diff));
range-diff.c +5 -5
@@ -39,7 +39,7 @@ struct patch_util {* as struct object_id (will need to be free()d). */ static int read_patches (const char *range,struct string_list *list, -const struct strvec *other_arg, +const struct strvec *log_arg,unsigned int include_merges) {struct child_process cp =CHILD_PROCESS_INIT ;
@@ -69,8 +69,8 @@ static int read_patches(const char *range, struct string_list *list,if (!include_merges)strvec_push (&cp.args,"--no-merges" );strvec_push (&cp.args, range); -if (other_arg) -strvec_pushv (&cp.args, other_arg->v); +if (log_arg) +strvec_pushv (&cp.args, log_arg->v); cp.out =-1 ; cp.no_stdin =1 ; cp.git_cmd =1 ;
@@ -594,9 +594,9 @@ int show_range_diff(const char *range1, const char *range2,if (range_diff_opts->left_only && range_diff_opts->right_only) res =error (_ ("options '%s' and '%s' cannot be used together" ),"--left-only" ,"--right-only" ); -if (!res &&read_patches (range1, &branch1, range_diff_opts->other_arg, include_merges)) +if (!res &&read_patches (range1, &branch1, range_diff_opts->log_arg, include_merges)) res =error (_ ("could not parse log for '%s'" ), range1); -if (!res &&read_patches (range2, &branch2, range_diff_opts->other_arg, include_merges)) +if (!res &&read_patches (range2, &branch2, range_diff_opts->log_arg, include_merges)) res =error (_ ("could not parse log for '%s'" ), range2);if (!res) {
range-diff.h +1 -1
@@ -23,7 +23,7 @@ struct range_diff_options { unsigned include_merges:1;size_t max_memory;const struct diff_options *diffopt;/* may be NULL */ -const struct strvec *other_arg;/* may be NULL */ +const struct strvec *log_arg;/* may be NULL */ };/*
revision.h +2 -1
@@ -334,7 +334,7 @@ struct rev_info {/* range-diff */ const char *rdiff1;const char *rdiff2; -struct strvec rdiff_other_arg; +struct strvec rdiff_log_arg;int creation_factor;const char *rdiff_title;
@@ -411,6 +411,7 @@ struct rev_info { .expand_tabs_in_log = -1, \ .commit_format = CMIT_FMT_DEFAULT, \ .expand_tabs_in_log_default = 8, \ + .rdiff_log_arg = STRVEC_INIT, \ }/**
Range-diff against v1:
-: ----------- > 1: bd037df14f5 range-diff: rename other_arg to log_arg 1: bb065767336 ! 2: d9419743773 revision: add rdiff_other_arg to rev_info
@@ Metadata
Author: Kristoffer Haugsbakk <[email protected]>
## Commit message ##
- revision: add rdiff_other_arg to rev_info
-
- git-format-patch(1) needs to pass --[no-]notes options on to the
- range-diff subprocess in range-diff.c. This is handled in `builtin/
- log.c by the local variable other_arg` in the case of multiple
- commits, but not in the single commit case where there is no cover
- letter and the range-diff is on that single resulting patch; the
- range-diff is then made in log-tree.c, whither other_arg has not
- been propagated.
-
- git-format-patch(1) is supposed to treat Git notes the same between
- notes output beneath the commit message and the notes output for the
- range-diff. But this lack of notes handling in log-tree.c breaks
- that expected behavior; range-diff notes handling for a single patch
- acts like a normal git-range-diff(1) invocation with regards to notes.
- You can, for example, end up with a patch where the note beneath the
- commit message has the correct notes namespace, but the range-diff has
- all the notes that are configured to be displayed by git-log(1).[1]
-
- We need to fix this. But first lay the groundwork by converting
- other_arg to a struct member; next we can simply use that member
+ revision: add rdiff_log_arg to rev_info
+
+ git-format-patch(1) supports Git notes by showing them beneath the
+ patch/commit message, similar to git-log(1). The command also supports
+ showing those same notes ref names in the range diff output.
+
+ Note *the same* ref names; any Git notes options or configuration
+ variables need to be handed off to the range-diff machinery. This works
+ correctly in the case when the range diff is on the cover letter. But it
+ does not work correctly when the output is a single patch with an
+ embedded range diff.
+
+ Concretely, git-format-patch(1) needs to pass --[no-]notes options
+ on to the range-diff subprocess in range-diff.c. This is handled in
+ builtin/log.c by the local variable log_arg in the case of mul-
+ tiple commits, but not in the single commit case where there is no
+ cover letter and the range diff is embedded in the patch output; the
+ range diff is then made in log-tree.c, whither log_arg has not
+ been propagated. This means that the range-diff subprocess reverts
+ to its default behavior, which is to act like git-log(1) w.r.t. notes.
+
+ We need to fix this. But first lay the groundwork by converting
+ log_arg to a struct member; next we can simply use that member
in log-tree.c without having to thread it from builtin/log.c.
No functional changes.
- † 1: See the configuration variable format.notes for git-format-
- patch(1); c.f. notes.displayRef for git-log(1). These two
- have nothing to do with each other.
-
+ Helped-by: Junio C Hamano <[email protected]>
## Notes (series) ##
+ v2:
+
+ Rewrite the commit message. The message jumps into the problem without
+ setting the stage. I think the problem should be presented for a future
+ reader with only some basic prerequisite knowledge of this area; they
+ might use git-format-patch(1), but they might not use Git notes *with*
+ format-patch.[1] For that reason, start with two paragraphs that pre-
+ sent how notes are handled. Then continue with the story in a format
+ similar to v1.
+
+ Note that the different “range diff” and “range-diff” spellings are
+ intentional. “Range diff” here refers to the diff output while
+ “range-diff” refers to the machinery that creates that output.
+
+ † 1: I don’t really see much Git notes use on patches on this mailing
+ list. And even less with non-default namespaces. But in any case:
+ the stage should be set properly even if regulars here *did* use
+ format-patch notes a lot.
+
+ Also fix handling of struct-in-struct (helped by Junio).
+
+ • Rewrite the commit message
+ • Fix struct-in-struct
+ • (And) Reset author date. I started this in June but the time
+ investment is mostly from these last days.
+
+ v1:
+
There is also other_arg in builtin/range-diff.c but rev_info does not seem to be involved.
@@ builtin/log.c: static void make_cover_letter(struct rev_info *rev, int use_separ
* can be added later if deemed desirable.
*/
struct diff_options opts;
-- struct strvec other_arg = STRVEC_INIT;
+- struct strvec log_arg = STRVEC_INIT;
struct range_diff_options range_diff_opts = {
.creation_factor = rev->creation_factor, .dual_color = 1,
.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT, .diffopt = &opts,
-- .other_arg = &other_arg
-+ .other_arg = &rev->rdiff_other_arg
+- .log_arg = &log_arg
++ .log_arg = &rev->rdiff_log_arg
};
repo_diff_setup(the_repository, &opts);
@@ builtin/log.c: static void make_cover_letter(struct rev_info *rev, int use_separ
opts.use_color = rev->diffopt.use_color; diff_setup_done(&opts);
fprintf_ln(rev->diffopt.file, "%s", rev->rdiff_title);
-- get_notes_args(&other_arg, rev);
+- get_notes_args(&log_arg, rev);
show_range_diff(rev->rdiff1, rev->rdiff2, &range_diff_opts);
-- strvec_clear(&other_arg);
+- strvec_clear(&log_arg);
}
}
@@ builtin/log.c: int cmd_format_patch(int argc,
rev.rdiff_title = diff_title(&rdiff_title, reroll_count,
_("Range-diff:"), _("Range-diff against v%d:"));
-+ get_notes_args(&(rev.rdiff_other_arg), &rev);
++ get_notes_args(&(rev.rdiff_log_arg), &rev);
}
/*
@@ builtin/log.c: int cmd_format_patch(int argc,
rev.diffopt.no_free = 0; release_revisions(&rev); format_config_release(&cfg);
-+ strvec_clear(&rev.rdiff_other_arg);
++ strvec_clear(&rev.rdiff_log_arg);
return 0;
}
@@ revision.h: struct rev_info {
/* range-diff */
const char *rdiff1;
const char *rdiff2;
-+ struct strvec rdiff_other_arg;
++ struct strvec rdiff_log_arg;
int creation_factor;
const char *rdiff_title;
+@@ revision.h: struct rev_info {
+ .expand_tabs_in_log = -1, \
+ .commit_format = CMIT_FMT_DEFAULT, \
+ .expand_tabs_in_log_default = 8, \
++ .rdiff_log_arg = STRVEC_INIT, \
+ }
+
+ /**
2: 7f2487af433 ! 3: 2be637081d4 format-patch: handle range-diff on notes correctly for single patches
@@ Metadata
## Commit message ##
format-patch: handle range-diff on notes correctly for single patches
- No --[no-]notes options are sent to the range-diff subprocess in
- range-diff.c when making a single patch. This means that you can get
- different Git notes below the commit message and in the range-diff
- part. (See the previous commit for elaboration.)
+ (The two next paragraphs are taken from the previous commit.)
- Use the struct member that we introduced and populated in the
+ git-format-patch(1) supports Git notes by showing them beneath the
+ patch/commit message, similar to git-log(1). The command also supports
+ showing those same notes ref names in the range diff output.
+
+ Note *the same* ref names; any Git notes options or configuration
+ variables need to be handed off to the range-diff machinery. This works
+ correctly in the case when the range diff is on the cover letter. But it
+ does not work correctly when the output is a single patch with an
+ embedded range diff.
+
+ Concretely, git-format-patch(1) needs to pass --[no-]notes options on
+ to the range-diff subprocess in range-diff.c. Range diffs for single-
+ commit series are handled in log-tree.c. But log-tree.c had no
+ access to any log_arg variable before we added it to rev_info in the
previous commit.
+ Use that new struct member to fix this inconsistency.
+
## Notes (series) ##
+ v1:
+
I’ve tried to conform to 6caa96c2 (t3206: test_when_finished before dirtying operations, not after, 2024-08-06) in the test here.
@@ log-tree.c: static void show_diff_of_diff(struct rev_info *opt)
.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
- .diffopt = &opts
+ .diffopt = &opts,
-+ .other_arg = &opt->rdiff_other_arg
++ .log_arg = &opt->rdiff_log_arg
};
memcpy(&dq, &diff_queued_diff, sizeof(diff_queued_diff));
base-commit: ca2559c1d630eb4f04cdee2328aaf1c768907a9e
Signature · 1 line
2.51.0.311.g9b2318464ce
PATCH v2 1/3 range-diff: rename other_arg to log_arg
From: Kristoffer Haugsbakk <[email protected]>
Rename other_arg to log_arg in range_diff_options and related places.
“Other argument” comes from bd361918 (range-diff: pass through --notes to git log, 2019-11-20) which introduced Git notes handling to git-range-diff(1) by passing that option on to git-log(1). And that kind of name might be fine in a local context. However, it was initially spread among multiple files, and is now[1] part of the range_diff_options struct. It is, prima facie, difficult to guess what “other” means, especially when just looking at the struct.
But with a little reading we find out that it is used for --[no-]notes and --diff-merges, which are both passed on to git-log(1). We should just rename it to reflect this role; log_arg suggests, along with the strvec type, that it is used to pass extra arguments to git-log(1).
† 1: since f1ce6c19 (range-diff: combine all options in a single data
structure, 2021-02-05)
---
Notes (series):
v2 (new):
Add a preliminary commit after discussing the other_arg name with Junio.
“ Back when it was a random one-shot variable in range-diff, it might
not have mattered all that much, but now we have it as a proper member of the struct, can we give it a name better than 'other_arg"?
Later:
“ My personal preference is to name arrays singular so that you can
name its 0th element by saying dog[0], not dogs[0]. "dog[1] and dog[2] are friends" not dogs[1] and dogs[2]. An exception is when most of the time you use the array as a single unit as a collection, passing it around in the call chain, rarely addressing each individual element. I am OK to see such an array called plural (but of course, singular names are always fine)..
And I chose singular to personal preference in this context (the use etc. for this kind of variable).
builtin/log.c | 8 ++++---- builtin/range-diff.c | 16 ++++++++-------- range-diff.c | 10 +++++----- range-diff.h | 2 +- 4 files changed, 18 insertions(+), 18 deletions(-)
builtin/log.c +4 -4
@@ -1400,13 +1400,13 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file,* can be added later if deemed desirable. */ struct diff_options opts; -struct strvec other_arg =STRVEC_INIT ; +struct strvec log_arg =STRVEC_INIT ;struct range_diff_options range_diff_opts = { .creation_factor = rev->creation_factor, .dual_color =1 , .max_memory =RANGE_DIFF_MAX_MEMORY_DEFAULT , .diffopt = &opts, - .other_arg = &other_arg + .log_arg = &log_arg };repo_diff_setup (the_repository, &opts);
@@ -1414,9 +1414,9 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file, opts.use_color = rev->diffopt.use_color;diff_setup_done (&opts);fprintf_ln (rev->diffopt.file,"%s" , rev->rdiff_title); -get_notes_args (&other_arg, rev); +get_notes_args (&log_arg, rev);show_range_diff (rev->rdiff1, rev->rdiff2, &range_diff_opts); -strvec_clear (&other_arg); +strvec_clear (&log_arg); } }
builtin/range-diff.c +8 -8
@@ -37,13 +37,13 @@ int cmd_range_diff(int argc, struct repository *repo UNUSED) {struct diff_options diffopt = {NULL }; -struct strvec other_arg =STRVEC_INIT ; +struct strvec log_arg =STRVEC_INIT ;struct strvec diff_merges_arg =STRVEC_INIT ;struct range_diff_options range_diff_opts = { .creation_factor =RANGE_DIFF_CREATION_FACTOR_DEFAULT , .max_memory =RANGE_DIFF_MAX_MEMORY_DEFAULT , .diffopt = &diffopt, - .other_arg = &other_arg + .log_arg = &log_arg };int simple_color =-1 , left_only =0 , right_only =0 ;struct option range_diff_options[] = {
@@ -52,7 +52,7 @@ int cmd_range_diff(int argc, N_("percentage by which creation is weighted")),OPT_BOOL (0 ,"no-dual-color" , &simple_color,N_ ("use simple diff colors" )), -OPT_PASSTHRU_ARGV (0 ,"notes" , &other_arg, +OPT_PASSTHRU_ARGV (0 ,"notes" , &log_arg,N_ ("notes" ),N_ ("passed to 'git log'" ),PARSE_OPT_OPTARG ), OPT_PASSTHRU_ARGV(0, "diff-merges", &diff_merges_arg,
@@ -92,7 +92,7 @@ int cmd_range_diff(int argc,/* If `--diff-merges` was specified, imply `--merges` */ if (diff_merges_arg.nr) { range_diff_opts.include_merges =1 ; -strvec_pushv (&other_arg, diff_merges_arg.v); +strvec_pushv (&log_arg, diff_merges_arg.v); }for (i =0 ; i < argc; i++)
@@ -124,7 +124,7 @@ int cmd_range_diff(int argc,strbuf_addf (&range1,"%s..%s" , argv[0 ], argv[1 ]);strbuf_addf (&range2,"%s..%s" , argv[0 ], argv[2 ]); -strvec_pushv (&other_arg, argv + +strvec_pushv (&log_arg, argv + (dash_dash <0 ?3 : dash_dash)); } else if (dash_dash == 2 || (dash_dash < 0 && argc > 1 &&
@@ -144,7 +144,7 @@ int cmd_range_diff(int argc,strbuf_addstr (&range1, argv[0 ]);strbuf_addstr (&range2, argv[1 ]); -strvec_pushv (&other_arg, argv + +strvec_pushv (&log_arg, argv + (dash_dash <0 ?2 : dash_dash)); } else if (dash_dash == 1 || (dash_dash < 0 && argc > 0 &&
@@ -175,7 +175,7 @@ int cmd_range_diff(int argc,strbuf_addf (&range1,"%s..%.*s" , b, a_len, a);strbuf_addf (&range2,"%.*s..%s" , a_len, a, b); -strvec_pushv (&other_arg, argv + +strvec_pushv (&log_arg, argv + (dash_dash <0 ?1 : dash_dash)); }else usage_msg_opt(_("need two commit ranges"),
@@ -187,7 +187,7 @@ int cmd_range_diff(int argc, range_diff_opts.right_only = right_only; res =show_range_diff (range1.buf, range2.buf, &range_diff_opts); -strvec_clear (&other_arg); +strvec_clear (&log_arg);strvec_clear (&diff_merges_arg);strbuf_release (&range1);strbuf_release (&range2);
range-diff.c +5 -5
@@ -39,7 +39,7 @@ struct patch_util {* as struct object_id (will need to be free()d). */ static int read_patches (const char *range,struct string_list *list, -const struct strvec *other_arg, +const struct strvec *log_arg,unsigned int include_merges) {struct child_process cp =CHILD_PROCESS_INIT ;
@@ -69,8 +69,8 @@ static int read_patches(const char *range, struct string_list *list,if (!include_merges)strvec_push (&cp.args,"--no-merges" );strvec_push (&cp.args, range); -if (other_arg) -strvec_pushv (&cp.args, other_arg->v); +if (log_arg) +strvec_pushv (&cp.args, log_arg->v); cp.out =-1 ; cp.no_stdin =1 ; cp.git_cmd =1 ;
@@ -594,9 +594,9 @@ int show_range_diff(const char *range1, const char *range2,if (range_diff_opts->left_only && range_diff_opts->right_only) res =error (_ ("options '%s' and '%s' cannot be used together" ),"--left-only" ,"--right-only" ); -if (!res &&read_patches (range1, &branch1, range_diff_opts->other_arg, include_merges)) +if (!res &&read_patches (range1, &branch1, range_diff_opts->log_arg, include_merges)) res =error (_ ("could not parse log for '%s'" ), range1); -if (!res &&read_patches (range2, &branch2, range_diff_opts->other_arg, include_merges)) +if (!res &&read_patches (range2, &branch2, range_diff_opts->log_arg, include_merges)) res =error (_ ("could not parse log for '%s'" ), range2);if (!res) {
range-diff.h +1 -1
@@ -23,7 +23,7 @@ struct range_diff_options { unsigned include_merges:1;size_t max_memory;const struct diff_options *diffopt;/* may be NULL */ -const struct strvec *other_arg;/* may be NULL */ +const struct strvec *log_arg;/* may be NULL */ };/*
Signature · 1 line
2.51.0.311.g9b2318464ce
PATCH v2 2/3 revision: add rdiff_log_arg to rev_info
In reply to [email protected]From: Kristoffer Haugsbakk <[email protected]>
git-format-patch(1) supports Git notes by showing them beneath the patch/commit message, similar to git-log(1). The command also supports showing those same notes ref names in the range diff output.
Note *the same* ref names; any Git notes options or configuration variables need to be handed off to the range-diff machinery. This works correctly in the case when the range diff is on the cover letter. But it does not work correctly when the output is a single patch with an embedded range diff.
Concretely, git-format-patch(1) needs to pass --[no-]notes options on to the range-diff subprocess in range-diff.c. This is handled in builtin/log.c by the local variable log_arg in the case of mul- tiple commits, but not in the single commit case where there is no cover letter and the range diff is embedded in the patch output; the range diff is then made in log-tree.c, whither log_arg has not been propagated. This means that the range-diff subprocess reverts to its default behavior, which is to act like git-log(1) w.r.t. notes.
We need to fix this. But first lay the groundwork by converting log_arg to a struct member; next we can simply use that member in log-tree.c without having to thread it from builtin/log.c.
No functional changes.
---
Notes (series):
v2:
Rewrite the commit message. The message jumps into the problem without setting the stage. I think the problem should be presented for a future reader with only some basic prerequisite knowledge of this area; they might use git-format-patch(1), but they might not use Git notes *with* format-patch.[1] For that reason, start with two paragraphs that pre- sent how notes are handled. Then continue with the story in a format similar to v1.
Note that the different “range diff” and “range-diff” spellings are intentional. “Range diff” here refers to the diff output while “range-diff” refers to the machinery that creates that output.
† 1: I don’t really see much Git notes use on patches on this mailing
list. And even less with non-default namespaces. But in any case:
the stage should be set properly even if regulars here *did* use format-patch notes a lot.
Also fix handling of struct-in-struct (helped by Junio).
• Rewrite the commit message
• Fix struct-in-struct
• (And) Reset author date. I started this in June but the time investment is mostly from these last days.
v1:
There is also other_arg in builtin/range-diff.c but rev_info does not seem to be involved.
builtin/log.c | 7 +++---- revision.h | 2 ++ 2 files changed, 5 insertions(+), 4 deletions(-)
builtin/log.c +3 -4
@@ -1400,13 +1400,12 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file,* can be added later if deemed desirable. */ struct diff_options opts; -struct strvec log_arg =STRVEC_INIT ;struct range_diff_options range_diff_opts = { .creation_factor = rev->creation_factor, .dual_color =1 , .max_memory =RANGE_DIFF_MAX_MEMORY_DEFAULT , .diffopt = &opts, - .log_arg = &log_arg + .log_arg = &rev->rdiff_log_arg };repo_diff_setup (the_repository, &opts);
@@ -1414,9 +1413,7 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file, opts.use_color = rev->diffopt.use_color;diff_setup_done (&opts);fprintf_ln (rev->diffopt.file,"%s" , rev->rdiff_title); -get_notes_args (&log_arg, rev);show_range_diff (rev->rdiff1, rev->rdiff2, &range_diff_opts); -strvec_clear (&log_arg); } }
@@ -2328,6 +2325,7 @@ int cmd_format_patch(int argc, rev.rdiff_title =diff_title (&rdiff_title, reroll_count,_ ("Range-diff:" ),_ ("Range-diff against v%d:" )); +get_notes_args (&(rev.rdiff_log_arg), &rev); }/*
@@ -2487,6 +2485,7 @@ int cmd_format_patch(int argc, rev.diffopt.no_free =0 ;release_revisions (&rev);format_config_release (&cfg); +strvec_clear (&rev.rdiff_log_arg);return 0 ; }
revision.h +2 -0
@@ -334,6 +334,7 @@ struct rev_info {/* range-diff */ const char *rdiff1;const char *rdiff2; +struct strvec rdiff_log_arg;int creation_factor;const char *rdiff_title;
@@ -410,6 +411,7 @@ struct rev_info { .expand_tabs_in_log = -1, \ .commit_format = CMIT_FMT_DEFAULT, \ .expand_tabs_in_log_default = 8, \ + .rdiff_log_arg = STRVEC_INIT, \ }/**
Signature · 1 line
2.51.0.311.g9b2318464ce
PATCH v2 3/3 format-patch: handle range-diff on notes correctly for single patches
In reply to [email protected]From: Kristoffer Haugsbakk <[email protected]>
(The two next paragraphs are taken from the previous commit.)
git-format-patch(1) supports Git notes by showing them beneath the patch/commit message, similar to git-log(1). The command also supports showing those same notes ref names in the range diff output.
Note *the same* ref names; any Git notes options or configuration variables need to be handed off to the range-diff machinery. This works correctly in the case when the range diff is on the cover letter. But it does not work correctly when the output is a single patch with an embedded range diff.
Concretely, git-format-patch(1) needs to pass --[no-]notes options on to the range-diff subprocess in range-diff.c. Range diffs for single- commit series are handled in log-tree.c. But log-tree.c had no access to any log_arg variable before we added it to rev_info in the previous commit.
Use that new struct member to fix this inconsistency.
---
Notes (series):
v1:
I’ve tried to conform to 6caa96c2 (t3206: test_when_finished before dirtying operations, not after, 2024-08-06) in the test here.
log-tree.c | 3 ++- t/t3206-range-diff.sh | 16 +++++++++++++++- 2 files changed, 17 insertions(+), 2 deletions(-)
log-tree.c +2 -1
@@ -718,7 +718,8 @@ static void show_diff_of_diff(struct rev_info *opt) .creation_factor = opt->creation_factor, .dual_color = 1, .max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT, - .diffopt = &opts + .diffopt = &opts, + .log_arg = &opt->rdiff_log_arg };memcpy (&dq, &diff_queued_diff,sizeof (diff_queued_diff));
t/t3206-range-diff.sh +15 -1
@@ -707,7 +707,7 @@ test_expect_success 'format-patch --range-diff does not compare notes by default ! grep "note" 0000-* ' -test_expect_success 'format-patch --notes=custom --range-diff only compares custom notes' ' +test_expect_success 'format-patch --notes=custom --range-diff --cover-letter only compares custom notes' ' test_when_finished "git notes remove topic unmodified || :" && git notes add -m "topic note" topic && git notes add -m "unmodified note" unmodified &&
@@ -721,6 +721,20 @@ test_expect_success 'format-patch --notes=custom --range-diff only compares cust ! grep "## Notes ##" 0000-* ' +# --range-diff on a single commit requires --no-cover-letter +test_expect_success 'format-patch --notes=custom --range-diff on single commit only compares custom notes' ' + test_when_finished "git notes remove HEAD unmodified || :" && + git notes add -m "topic note" HEAD && + test_when_finished "git notes --ref=custom remove HEAD unmodified || :" && + git notes add -m "unmodified note" unmodified && + git notes --ref=custom add -m "topic note (custom)" HEAD && + git notes --ref=custom add -m "unmodified note (custom)" unmodified && + git format-patch --notes=custom --range-diff=$prev \ + -1 --stdout >actual && + test_grep "## Notes (custom) ##" actual && + test_grep ! "## Notes ##" actual +' + test_expect_success 'format-patch --range-diff with --no-notes' ' test_when_finished "git notes remove topic unmodified || :" && git notes add -m "topic note" topic &&
Signature · 1 line
2.51.0.311.g9b2318464ce