From: Junio C Hamano <gitster@pobox.com>
To: kristofferhaugsbakk@fastmail.com
Cc: git@vger.kernel.org, Kristoffer Haugsbakk <code@khaugsbakk.name>,
"D . Ben Knoble" <ben.knoble@gmail.com>
Subject: Re: [PATCH v3 2/2] format-patch: learn --[no-]range-diff-notes
Date: Fri, 02 Oct 2026 10:28:09 -0700 [thread overview]
Message-ID: <xmqqy0cgvwpi.fsf@gitster.g> (raw)
In-Reply-To: <V3_format-patch_learn_--range-diff-notes.d3b@m5gid.xyz> (kristofferhaugsbakk@fastmail.com's message of "Fri, 2 Oct 2026 12:56:39 +0200")
kristofferhaugsbakk@fastmail.com writes:
> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>
> git-format-patch(1) passes on the notes behavior that it is using for
> the patches to git-range-diff(1). In turn you get the same Git notes
> displayed in the range diff as the ones you used to generate the
> patches. And that makes sense in most cases.
>
> However, I often make notes between series versions that mostly prepend
> ...
> something like an alias set up with it. But why spend code closing
> that door? There is no usability upside to erroring out.
This is somewhat shared with the next step, but the commit message
includes a lengthy narrative of the author's thought process ("An
off/on switch is enough for this behavior...", "But now we are faced
with a problem...", "Well, we can't. Therefore we need...").
Can we strip out the conversational journey? The log message should
be a concise, permanent technical reference explaining the problem
(range diff notes inherit patch notes, which may contain irrelevant
iteration changelogs) and the solution (the new options and the
.override flag).
> diff --git a/Documentation/git-format-patch.adoc b/Documentation/git-format-patch.adoc
> index 191f64b77d1..5907f299a8d 100644
> --- a/Documentation/git-format-patch.adoc
> +++ b/Documentation/git-format-patch.adoc
> @@ -378,6 +378,21 @@ case is to show comparison with an older iteration of the same
> topic and the tool should find more correspondence between the two
> sets of patches.
>
> +`--range-diff-notes=<ref>`::
> +`--no-range-diff-notes`::
> + Used with `--range-diff`, tweak what notes to display in the
> + range diff.
> ++
> +The default behavior is to display the same notes in the range diff as
> +on the patches; see `--notes`. But you can use these options to use a
> +different list of notes. For example, say you have given three notes
> +refs to `--notes`. At this point those same three notes will be
> +displayed in the range diff. But then you pass
> +`--range-diff-notes=<ref>`. Now the range diff will only display
> +_<ref>_. You can of course pass more refs to this option, just like
> +`--notes`. And you can also turn off all range diff notes with
> +`--no-range-diff-notes`.
Very chatty and colloquial. A technical reference manual should be
concise and direct. Here is my attempt to condense it down to make
it more readable:
By default, '--range-diff' displays the same notes as the patches
(see '--notes'). Use '--range-diff-notes=<ref>' to specify a
different notes ref for the range diff. This option can be given
multiple times to show notes from multiple refs. Use
'--no-range-diff-notes' to disable notes in the range diff.
> diff --git a/builtin/log.c b/builtin/log.c
> index 560af00e2fd..d70101f0755 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -1327,15 +1327,56 @@ static void prepare_cover_text(struct pretty_print_context *pp,
> strbuf_release(&subject_sb);
> }
>
> +struct rdiff_notes {
> + /*
> + * True if we want to override the notes behavior
> + * of 'format-patch'
> + */
> + bool override;
> + struct string_list notes;
> +};
> +
> +static int rdiff_notes_cb(const struct option *option,
> + const char *arg,
> + int unset)
> +{
> + struct rdiff_notes *rdiff_notes = option->value;
> +
> + rdiff_notes->override = 1;
> +
> + /*
> + * The rest is the same as
> + * parse-options-cb.c:parse_opt_string_list
> + */
Hmph, I wonder if it is more future-proof to wrap the string-list
callback like so ...
static int rdiff_notes_cb(const struct option *option,
const char *arg,
int unset)
{
struct option opt = *option;
struct rdiff_notes *rdiff_notes = opt.value;
rdiff_notes->override = 1;
opt.value = &rdiff_notes->notes;
return parse_opt_string_list(&opt, arg, unset);
}
... than copying and letting the code drift apart.
next prev parent reply other threads:[~2026-10-02 17:28 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 20:35 [PATCH 0/3] format-patch: learn --[no-]range-diff-notes kristofferhaugsbakk
2026-08-24 20:35 ` [PATCH 1/3] format-patch: simplify get_notes_arg parameters kristofferhaugsbakk
2026-08-24 20:35 ` [PATCH 2/3] revision.h: rename struct member to reflect notes role kristofferhaugsbakk
2026-08-24 20:35 ` [PATCH 3/3] format-patch: learn --[no-]range-diff-notes kristofferhaugsbakk
2026-08-24 22:31 ` Junio C Hamano
2026-08-25 18:36 ` Kristoffer Haugsbakk
2026-08-28 0:31 ` Junio C Hamano
2026-08-28 13:48 ` Kristoffer Haugsbakk
2026-08-28 17:13 ` Junio C Hamano
2026-09-02 13:19 ` Kristoffer Haugsbakk
2026-09-06 7:22 ` Kristoffer Haugsbakk
2026-09-06 13:37 ` D. Ben Knoble
2026-09-06 16:44 ` Kristoffer Haugsbakk
2026-09-06 17:57 ` D. Ben Knoble
2026-09-06 17:12 ` Junio C Hamano
2026-09-09 18:08 ` Kristoffer Haugsbakk
2026-09-09 19:04 ` Junio C Hamano
2026-09-26 18:27 ` [PATCH v2 0/2] " kristofferhaugsbakk
2026-09-26 18:27 ` [PATCH v2 1/2] format-patch: simplify get_notes_arg parameters kristofferhaugsbakk
2026-09-26 18:27 ` [PATCH v2 2/2] format-patch: learn --[no-]range-diff-notes kristofferhaugsbakk
2026-09-27 12:50 ` Junio C Hamano
2026-09-27 19:42 ` Kristoffer Haugsbakk
2026-09-28 15:35 ` Junio C Hamano
2026-09-28 15:53 ` Kristoffer Haugsbakk
2026-10-02 10:56 ` [PATCH v3 0/2] " kristofferhaugsbakk
2026-10-02 10:56 ` [PATCH v3 1/2] format-patch: simplify get_notes_arg parameters kristofferhaugsbakk
2026-10-02 16:50 ` Junio C Hamano
2026-10-02 18:51 ` Kristoffer Haugsbakk
2026-10-02 19:07 ` Kristoffer Haugsbakk
2026-10-02 19:13 ` Kristoffer Haugsbakk
2026-10-02 10:56 ` [PATCH v3 2/2] format-patch: learn --[no-]range-diff-notes kristofferhaugsbakk
2026-10-02 17:28 ` Junio C Hamano [this message]
2026-10-02 18:56 ` Kristoffer Haugsbakk
2026-10-04 10:17 ` [PATCH v4 0/2] " kristofferhaugsbakk
2026-10-04 10:17 ` [PATCH v4 1/2] format-patch: simplify get_notes_arg parameters kristofferhaugsbakk
2026-10-04 10:17 ` [PATCH v4 2/2] format-patch: learn --[no-]range-diff-notes kristofferhaugsbakk
2026-10-04 16:25 ` Junio C Hamano
2026-10-04 17:30 ` Kristoffer Haugsbakk
2026-10-04 17:58 ` [PATCH v5 0/2] " kristofferhaugsbakk
2026-10-04 17:58 ` [PATCH v5 1/2] format-patch: simplify get_notes_arg parameters kristofferhaugsbakk
2026-10-04 17:58 ` [PATCH v5 2/2] format-patch: learn --[no-]range-diff-notes kristofferhaugsbakk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy0cgvwpi.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=code@khaugsbakk.name \
--cc=git@vger.kernel.org \
--cc=kristofferhaugsbakk@fastmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.