Re: [PATCH v3 3/9] doc: trailer: drop "commit message part" phrasing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 6, 2023 at 4:08 AM Linus Arver via GitGitGadget
<gitgitgadget@xxxxxxxxx> wrote:
>
> From: Linus Arver <linusa@xxxxxxxxxx>
>
> The command can take inputs that are either just a commit message, or
> an email-like output such as git-format-patch which includes a commit
> message, "---" divider, and patch part. The existing explanation blends
> these two inputs together in the first sentence
>
>     This command reads some patches or commit messages
>
> which then necessitates using the "commit message part" phrasing (as
> opposed to just "commit message") because the input is ambiguous per the
> above definition.
>
> This change separates the two input types and explains them separately,
> and so there is no longer a need to use the "commit message part"
> phrase.
>
> Signed-off-by: Linus Arver <linusa@xxxxxxxxxx>
> ---
>  Documentation/git-interpret-trailers.txt | 35 +++++++++++++-----------
>  1 file changed, 19 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt
> index da8fec7d5fe..ffde97a6c3d 100644
> --- a/Documentation/git-interpret-trailers.txt
> +++ b/Documentation/git-interpret-trailers.txt
> @@ -18,17 +18,22 @@ Add or parse 'trailer' lines that look similar to RFC 822 e-mail
>  headers, at the end of the otherwise free-form part of a commit
>  message.
>
> -This command reads some patches or commit messages from either the
> -<file> arguments or the standard input if no <file> is specified. If
> -`--parse` is specified, the output consists of the parsed trailers.
> -
> +This command reads commit messages from either the
> +<file> arguments or the standard input if no <file> is specified.
> +If `--parse` is specified, the output consists of the parsed trailers.
>  Otherwise, this command applies the arguments passed using the
> -`--trailer` option, if any, to the commit message part of each input
> -file. The result is emitted on the standard output.
> +`--trailer` option, if any, to each input file. The result is emitted on the
> +standard output.
> +
> +This command can also operate on the output of linkgit:git-format-patch[1],
> +which is more elaborate than a plain commit message. Namely, such output
> +includes a commit message (as above), a "---" divider line, and a patch part.
> +For these inputs, the divider and patch parts are ignored, unless `--no-divider`
> +is specified.

I think saying "the divider and patch parts are ignored" is a bit
ambiguous. It could mean that when a patch is read by the command only
its commit message, possibly modified by the command, is emitted on
the standard output.

I would suggest something like:

"For these inputs, the divider and patch parts are not modified by
this command and are emitted as is on the output, unless
`--no-divider` is specified."




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux