> Yeah, but you can perhaps check that the input doesn't contain '|' > before doing the above. If it does contain '|' then you can probably > find another char that it doesn't contain and use that char instead of > '|'. This sounds true in the usual case, though of course there are pathological cases of commit messages that use the entire character set. But it is starting to sound more complicated than the slightly-tricky whitespace indexing logic from my original message. > Another solution would be to develop a trailer.outputseparator config > option, which should not be very difficult. Yes, something like this would be a nice addition for future versions of Git. Perhaps simpler would be to add a `-z` option to interpret-trailers that would change the output format to <tok>NUL<val>NUL or similar. Maybe I’ll send out a patch if I find some free time. :-) Best, WC On Tue, Dec 25, 2018 at 8:33 PM Christian Couder <christian.couder@xxxxxxxxx> wrote: > > Hi William, > > On Mon, Dec 24, 2018 at 7:52 PM William Chargin <wchargin@xxxxxxxxx> wrote: > > > > Hi Christian: thanks for your reply. > > > > > Changing the default separator as shown above, should make it easier > > > to parse the result. > > > > But this actually also changes which lines are considered trailers, > > right? > > Yes. > > > If the commit message ends with > > > > Signed-off-by: one > > Signed-off-by| two > > > > and the user’s `trailer.separators` is set to `:`, then the correct > > result should be only `Signed-off-by: one`. But when adding `|` as a > > separator, we also see `Signed-off-by: two` in the result. > > Yeah, but you can perhaps check that the input doesn't contain '|' > before doing the above. If it does contain '|' then you can probably > find another char that it doesn't contain and use that char instead of > '|'. > > Another solution would be to develop a trailer.outputseparator config > option, which should not be very difficult. > > Best, > Christian.
