On Sun, Oct 25, 2020 at 10:26:44PM +0100, Anders Waldenborg wrote: > Adds a new `--(no-)canonicalize` option to interpret-trailers. By > default it is on unless `--parse` option is given. > > When option is on trailer tokens and separators get canonicalized to > the form they have in config (if there is any config for that > trailer). This is same behavior as before this patch, which allows > this behavior to be disabled with `--no-canonicalize`. `--parse` now > also implies `--no-canonicalize`, if previous behavior with > canonicalization also in parse mode is wanted it needs to be combined > with `--parse --canonicalize` I'm not sure if this should be tied to --parse or not. The idea of --parse is that you'd normalize syntactic issues to make it easy to parse the result. But wouldn't normalizing names around spelling or capitalization be what you'd usually want there? So it sounds like you'd want it to _always_ be on, but leave "--no-canonicalize" as an escape hatch for somebody who's researching spelling variants. Or maybe I'm misunderstanding what it does, since... > --- a/Documentation/git-interpret-trailers.txt > +++ b/Documentation/git-interpret-trailers.txt > @@ -129,13 +129,16 @@ OPTIONS > > --parse:: > A convenience alias for `--only-trailers --only-input > - --unfold`. > + --unfold --no-canonicalize`. > > --no-divider:: > Do not treat `---` as the end of the commit message. Use this > when you know your input contains just the commit message itself > (and not an email or the output of `git format-patch`). > > +--no-canonicalize:: > + Disable canonicalization of input trailers. I think this needs to define "canonicalization" here. -Peff
