Oswald Buddenhagen <oswald.buddenhagen@xxxxxx> writes: > but i wouldn't be opposed to for example git-mailinfo learning to > understand the --pretty argument, if the implementation doesn't turn > out to be completely out of proportion. Excellent suggestion. I agree that 'mailinfo' would be the closest place we have for such a new feature. It's "info" output (i.e. what comes out to the standard output of the command) is designed to be extensible, and I vaguely recall that we indeed have added new field(s) during its lifetime with existing users already. We can just invent a new label (e.g. "Filesystem-safe-subject:"), pass the subject string to pretty.c:format_sanitized_subject() and emit the result next to the existing "Subject:" with that label, and we can even do so unconditionally without breaking anybody. Having it in 'mailinfo' may still not be a good solution to the issue, given that Vit says >> But I typically don't have a Git. though. On a related not-so-distant tangent, we probably should redo the support for --message-id to emit it as an extra entry to the "info" output, instead of contaminating the "message" output. The option was added only to support "git am --message-id", and as long as the calling "am" and "mailinfo" are updated in sync to use the "info" output to carry the Message-Id: information, we should be able to do such a clean-up without changing the externally visible behaviour.
