Re: [PATCH v4 2/2] format-patch: learn --[no-]range-diff-notes

["Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>]

On Sun, Oct 4, 2026, at 18:25, Junio C Hamano wrote:
> kristofferhaugsbakk@fastmail.com writes:
>>[snip]
>> ***
>> 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.
>
> In short, do you mean something like this?
>
>   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.

That’s a better way to describe it. I think I will use it pretty much
verbatim.

Now in hindsight, with your version on display in front of me, I don’t
know why I couldn’t make that paragraph more straighforward. Sometimes I
go on a narrative journey because I think it is clearer (but never
shorter), but here I didn’t want to do that at all. I just wanted to lay
out the motivation. Stumped.

>
> I suspect that erroring out when only creation-factor is given,
> perhaps via an alias, was a design mistake.  A user who wants to use
> a setting customized for their workflow must resort to an alias
> because there is no configuration variable to control its default.
> In that light, the same argument for --[no-]range-diff-notes applies
> here.  On the other hand, perhaps if we had a configuration variable
> to control which notes are compared in range-diff and shown in the
> output, we would not have to worry about these things.  I do not
> know.

Yeah it can prevent some workflows while not really helping prevent any
errors, I think.

I think I can make this next version right now. I have tried to give
more time to each version (like the last one, intentionally waiting more
than a day) in order to give other people time to react to them. However
at this point most of the changes in this series are so stable that I
don’t think there are any points to interject to for some hypotethetical
person that already had two days or so to speak up.

>[snip]