Skip to content

format-patch: learn --[no-]range-diff-notes

[email protected] git 5 versions – New

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v5 Latest2 patches 0 repliesNew
  2. v42 patches 2 repliesSuperseded
  3. v32 patches 6 repliesSuperseded
Earlier versions · 2
VersionPostedPatchesRepliesStatus
v22 patches4 repliesSuperseded
v13 patches13 repliesSuperseded

Patches in v5 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/2format-patch: simplify get_notes_arg parametersbuiltin/log.c+7 -50 replies
2/2format-patch: learn --[no-]range-diff-notesDocumentation/git-format-patch.adoc builtin/log.c t/t3206-range-diff.sh+136 -30 replies

Reviews trailers per patch

None of the 2 patches has a Reviewed-by or Acked-by.

PatchJunio C Hamano
1/2
2/2Helped-by

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v5 thread

Cover letter [PATCH v5 0/2] format-patch: learn --[no-]range-diff-notes

From: Kristoffer Haugsbakk <[email protected]>

Topic name (applied): kh/format-patch-range-diff-notes

Topic summary: Teach 'format-patch' options to tweak notes output in the range diff independent of what notes are output in the patches.

See patch 2/2 for details.

This is motivated by wanting to turn off range diff notes, but the goal here is to implement it in full generality.

(How many of us git format-patch --notes users are there out there? More than a dozen? Maybe just D. Ben Knoble and me?)

I have implemented this behavior for myself and used it for many months. But that was hacky and only suitable for one person’s use. So this is a completely new implementation. In other words: this is new code, *not* tested for months.

§ Changes in v5

Patch 2/2:

• Msg: Shorten paragraph about “why not error out like --creation-factor...” while keeping the exact same information.[1]
🔗 1: https://lore.kernel.org/git/[email protected]/
• Msg: ... Also drop the thematic breaks (***). I think the paragraphs flow well enough now to the point that they are not needed.

§ Link to v4

https://lore.kernel.org/git/[email protected]/

[1/2] format-patch: simplify get_notes_arg parameters [2/2] format-patch: learn --[no-]range-diff-notes

 Documentation/git-format-patch.adoc | 11 ++++
 builtin/log.c                       | 50 +++++++++++++++--
 t/t3206-range-diff.sh               | 86 +++++++++++++++++++++++++++++
 3 files changed, 141 insertions(+), 6 deletions(-)

Interdiff against v4:
Range-diff against v4:

1:  bb60f300d3f = 1:  bb60f300d3f format-patch: simplify get_notes_arg parameters
2:  4cbd312fec6 ! 2:  676361b383e format-patch: learn --[no-]range-diff-notes

@@ Commit message
1. No such options were given and empty list (use --notes)
2. Options were given and empty list (--no-... given; don’t use notes)

- ***
-
- Note that using --creation-factor without --range-diff will cause
- the command to die. But this is not the case for `--[no-]range-diff-
- notes; we would have to check rdiff_notes.override`, which is a sticky
- value (cannot be turned off). The reason is that it is potentially
- inconvenient to error out since it would not let you turn off
- --range-diff in, say, some alias that uses `--no-range-diff-
- notes`. Granted, it is difficult for me to come up with a concrete use
- case since --range-diff requires a value, specifically a value which
- is probably not that reusable (revision range), and yet you have
- something like an alias set up with it. But why spend code closing
- that door? There is no usability upside to erroring out.
-
- ***
+ Unlike --creation-factor, --[no-]range-diff-notes does not error out
+ when used without --range-diff. This flexibility accommodates
+ workflows where users might configure default options in aliases or
+ wrapper scripts, allowing --range-diff to be toggled independently.

Add two tests here for the single-patch case, i.e. the case where the range diff is on the patch and not in the cover letter. These are meant

base-commit: 1a3e64c6c4a623626ff0687008732a8e007e2a1c

Signature · 1 line
2.55.0.793.gc667de3f2c5