Re: [PATCH 4/5] interpret-trailers: add an option to normalize output

From: Christian Couder <christian.couder@gmail.com>
Date: Aug 11, 2017, 07:02 UTC
Message-ID: <CAP8UFD3RWByUBZf=E_EBCW2Zk7voogfB+Qpsx4U2YNq0T0Hqag@mail.gmail.com>
In-Reply-To: <20170810231038.4s2btsotoq76atuu@sigill.intra.peff.net>

On Fri, Aug 11, 2017 at 1:10 AM, Jeff King <peff@peff.net> wrote:

Show 6 quoted lines

> On Fri, Aug 11, 2017 at 12:02:49AM +0100, Ramsay Jones wrote:
>
>> > But some of those things are not 1:1 mappings with normalization.  For
>> > instance, --json presumably implies --only-trailers. Or are we proposing
>> > to break the whole commit message down into components and output it all
>> > as json?

Well who knows what people might want/need? Anyway in `git log` --oneline is not a direct mapping with --pretty=oneline as it also means --abbrev-commit, and this is not a big problem.

>> Hmm, to me the operation wasn't so much a normalization, rather
>> it was an --unfold (or maybe --un-fold ;-D). I suppose going in
>> the other direction could be --fold=72, or some such.

Yeah, we could call that --no-fold or --no-wrap if we expect to need --fold=72 or --wrap=72. At least it is more descriptive than --normalize and if we later introduce --pretty or --format we can say that it is a shorthand for --pretty=nofold or --pretty=unfolded.

Show 6 quoted lines

> But I really don't want callers to think of it as "unfold". I want it to
> be "turn this into something I can parse simply". Hence if we were to
> find another case where the output is irregular, I'd feel comfortable
> calling that a bug and fixing it (one that I suspect but haven't tested
> is that alternate separators probably should all be converted to
> colons).

Though "fixing" this after a release has been made might introduce a regression for people who would already use the option on trailers with different separators. That's also why I don't like --normalize. We just don't know if we will need to "fix" it a lot to make sure scripts using it will work in all cases.

If we use --no-fold or --oneline instead, we don't promise too much from this option, so users cannot say that they expect it to work for them in all cases.