Re: [PATCH v4 5/8] interpret-trailers: add --parse convenience option

From: Jeff King <peff@peff.net>
Date: Aug 16, 2017, 08:20 UTC
Message-ID: <20170816082022.5use3im2bq27wik4@sigill.intra.peff.net>
In-Reply-To: <CAN0heSrUz2jU2ijeSjYRhvyXA8qpw=JoOhaK-4Fuyv4_1L6Gtw@mail.gmail.com>

On Tue, Aug 15, 2017 at 01:26:53PM +0200, Martin Ågren wrote:

Show 13 quoted lines

> >  This command reads some patches or commit messages from either the
> > -<file> arguments or the standard input if no <file> is specified. Then
> > -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.
> > +<file> arguments or the standard input if no <file> is specified. If
> > +`--parse` is specified, the output consists of the parsed trailers.
> > +
> > +Otherwise, the 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.
> 
> "the this"

Thanks.

> I think I get why you use --parse above (and in the synopsis), although
> it kind of feels like it should be --only-input or perhaps "--only-input
> (or --parse)".

I really wanted to point people to --parse as the go-to option for the parsing mode for the sake of simplicity (in fact I initially considered not even exposing them at all). And I hoped that if they jumped to the definition of --parse, that would lead them to the other options.

I dunno. I agree it is does not read particularly well. Probably the whole description section could be rewritten to cover the newly dual nature of the command a bit better. But I didn't want to disrupt the existing flow too much.

-Peff