From: Tian Yuchen <cat@malon.dev>
To: "Jean-Noël AVILA" <avila.jn@gmail.com>, git@vger.kernel.org
Cc: gitster@pobox.com
Subject: Re: [PATCH v1] diff: document -U without <n> as using default context
Date: Wed, 11 Mar 2026 12:33:31 +0800 [thread overview]
Message-ID: <9fc9fb8b-5f91-4670-a674-76774c31d228@malon.dev> (raw)
In-Reply-To: <5973423.DvuYhMxLoT@piment-oiseau>
On 3/11/26 01:31, Jean-Noël AVILA wrote:
> In this case, isn't the long option also changed to optional number, such as:
>
> `--unified[=<n>]`
>
> ?
Indeed. Your statement aligns with what Junio said earlier.
>> The documentation for '-U<n>' implies that the numeric value '<n>' is
>> mandatory. However, the command line parser has historically accepted
>> '-U' without a number.
>>
>> Strictly requiring a number for '-U' would break existing tests
>> (e.g., in 't4013') and likely disrupt user scripts relying on this
>> undocumented behavior.
>>
>> Since we are retaining this fallback behavior for backward compatibility,
>> update the documentation to explicitly state that '<n>' can be omitted
>> for the short option '-U'.
>>
>> Signed-off-by: Tian Yuchen <cat@malon.dev>
>> ---
>> Documentation/diff-context-options.adoc | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> I am moderately nagative.
>
> It is not like we are _encouraging_ users to omit <n> from -U<n>,
> but it is not errored out only due to a bug. Who would the new text
> help? Users would wonder why <n> is not optional in --unified=<n>,
> the other way to spell the same thing.
>
> If we want to be explicit, we should probably do this instead:
>
> `-U<n>`::
> `--unified=<n>`::
> Generate diffs with _<n>_ lines of context. Defaults to `diff.context`
> or 3 if the config option is unset (`-U` without '<n>' is accepted
> as a silent synonym for `-p` due to a historical accident).
>
> which would tell readers what happens when '<n>' is omitted and why
> we allow such an inconsistency.
I have already fixed this in the v3 patch.
Thank you,
Yuchen
prev parent reply other threads:[~2026-03-11 4:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 23:10 An annoying "Bug" that we would probably leave as-is Junio C Hamano
2026-03-09 17:10 ` Tian Yuchen
2026-03-09 17:27 ` [PATCH v1] diff: document -U without <n> as using default context Tian Yuchen
2026-03-09 22:00 ` D. Ben Knoble
2026-03-10 4:55 ` Tian Yuchen
2026-03-09 22:17 ` Junio C Hamano
2026-03-10 4:51 ` Tian Yuchen
2026-03-10 5:30 ` [PATCH v2] " Tian Yuchen
2026-03-10 9:15 ` Oswald Buddenhagen
2026-03-10 9:43 ` Tian Yuchen
2026-03-10 13:14 ` Junio C Hamano
2026-03-10 9:50 ` [PATCH v3] " Tian Yuchen
2026-03-10 17:31 ` [PATCH v1] " Jean-Noël AVILA
2026-03-11 4:33 ` Tian Yuchen [this message]
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=9fc9fb8b-5f91-4670-a674-76774c31d228@malon.dev \
--to=cat@malon.dev \
--cc=avila.jn@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.