On Fri, Aug 11, 2017 at 1:10 AM, Jeff King <peff@xxxxxxxx> wrote: > 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. > 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.
