Re: [PATCH] format-patch: teach --no-encode-headers
- From
Emma Brooks <me@pluvano.com>
- Date
- Apr 8, 2020, 04:08 UTC
- Message-ID
- <20200408040746.GA41187@pluvano.com>
- In-Reply-To
- <xmqq8sj7t7d0.fsf@gitster.c.googlers.com>
On 2020-04-07 12:37:31-0700, Junio C Hamano wrote:
Show 21 quoted lines
> Emma Brooks <me@pluvano.com> 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.
Ah. I don't think there are any cases where we do other sorts of encoding, or want to enable one "part" of encoding and disable another. I do think the name need to be more obviously about *email* headers as Jeff pointed out, though.