Re: [ANNOUNCE] GIT 1.5.5-rc2

From: Jeff King <peff@peff.net>
Date: Mar 28, 2008, 21:23 UTC
Message-ID: <20080328212340.GC9131@coredump.intra.peff.net>
In-Reply-To: <7vtziq1rwa.fsf@gitster.siamese.dyndns.org>

On Fri, Mar 28, 2008 at 02:05:09PM -0700, Junio C Hamano wrote:

Show 8 quoted lines

> > I never got a response to my patches to fix encoding issues in
> > "send-email --compose". It _is_ a bugfix, but I don't know if it is
> > 1.5.5-worthy.  Forgotten (and I should resubmit now), or should I wait
> > until after the release?
> 
> I was getting the impression that it was still in "ah, but this is
> better", "you are right, but how about doing this", stage and was hoping
> that "ok, based on the discussion here is the final one" will come soon.

Ah. I think the current status is "here are two patches that work, but will always assume utf-8 encoding" which I think is not unreasonable as a bugfix. A nice feature would be to allow setting the encoding, but:

  - I think that is a feature, and one that nobody has expressed an
    interest in. In fact, the little rfc2047 encoding already being done
    in send-email blindly assumed utf-8.
  - if that feature is going to be done, I think some thought would have
    to go into how encodings should be specified so we don't end up with
    too many (or too few) places where you have to specify the encoding
    (IOW, I think that send-email.compose-encoding is probably too
    specific, but reusing an existing encoding variable is not quite
    right).
  - As a non-user of send-email, a rare user of encodings at all, and an
    always user of utf-8, I'm not too interested in such a feature, nor
    would I feel comfortable speaking on behalf of users who _would_ use
    such a feature.

So I think it is worth taking the patches for 1.5.5 as they are a strict improvement over the old behavior (the only reason they would not be is if somebody used a mail pipeline that assumed non-MIME stuff was in some random charset instead of us-ascii, and by setting utf-8 we are now confusing that pipeline; it seems unlikely to me, and it violates the standards).

On top of which I think they are a fine stepping stone to selecting the encoding (IOW, if I _were_ going to do such a feature, I think I would still submit those two patches as-is, and add configurability as a third patch anyway).

My only real concern is that they break something unrelated, as we are late in the -rc cycle.

-Peff