On Tue, Apr 07, 2020 at 12:37:31PM -0700, Junio C Hamano wrote: > Emma Brooks <me@xxxxxxxxxxx> writes: > > > It's also too vague and it's not entirely clear from the option itself > > what sort of encoding it refers to. I will change it to > > --[no-]q-encode-headers and format.qEncodeHeaders in v2 unless there are > > other suggestions. > > I actually did not mean to push you into that direction. We can, > and do want to, keep the most generic "--[no-]encode-headers" if we > do not anticipate us wanting to special case the Q encoding. A > sample question to ask is "would it make sense to disable q-encoding > but still perform other parts of 'encode headers'?" I haven't > thought deeply about such questions, but as a proposer of this > topic, you would certainly have, and I was hoping that you'd say > things like "Q-encoding is the only thing that we do to munge > headers, so there aren't any 'other parts of encoding headers' we > need to worry about", "there are things like X, Y and Z that we do > to the headers when we enable Q-encoding, but they all are what we > do not want when we do not want the Q-encoding", which would be a > very good sign that assures us that "--[no-]encode-headers" is a > good name. I thought we might b-encode some headers, but couldn't find any code to do so (after about 5 minutes of looking). However, this new option isn't just for format-patch. It is available for all revision walkers (as it should be; I can say "log --format=email" and I might want to use it there). And there "headers" is less clear that we are talking about email headers, and not other object headers (e.g., that you might see with --format=raw). Saying "--no-rfc2047-encoding" would be more descriptive to _me_, but I wonder if people not so familiar with the standards would find it a bit obscure. Another option is to invert it to "--8bit-email-headers" or something. -Peff
