Re: `git-send-email' doesn't specify `Content-Type'
- From
Björn Steinbrink <b.steinbrink@gmx.de>
- Date
- Nov 10, 2007, 12:25 UTC
- Message-ID
- <20071110122528.GA4977@atjola.homenet>
- In-Reply-To
- <20071110101420.GA21353@bulgaria>
On 2007.11.10 02:14:20 -0800, Brian Swetland wrote:
Show 24 quoted lines
> [Johannes Schindelin <Johannes.Schindelin@gmx.de>] > > Hi, > > > > On Sat, 10 Nov 2007, Ludovic Court?s wrote: > > > > > Apparently, `git-send-email' doesn't specify the email's `Content-Type', > > > notably its charset, while it should really add something like: > > > > > > Content-Type: text/plain; charset=UTF-8 > > > > > > Or did I miss an option or something? > > > > Apparently. There was a thread some days ago, about that very issue. > > Please find and read it. > > The thread I found says that git-send-email should do the right thing if > there are non-ascii characters, but this does not seem to be the case > for me. > > The example I have involves a coworker's name which needs non-ascii > characters. They are properly escaped in the From: line generated by > git-format-patch. git-send-email puts the generated From: line at the > top of the body of the email, unescapes it (to utf-8), and proceeds to > send the email with no Content-Type specified.
You mean that it converts the header field to utf-8? It doesn't do that here (neither master nor 1.5.3.5) and IIRC that would be invalid anyway, because Content-Type applies to exactly that, content, not headers. Your sample has no non-ASCII characters (or at least I didn't see any), so git-send-email doesn't add a header to specify a charset.
Björn
Show 37 quoted lines
> This behaviour is observed in 1.5.3.5. A sample output from
> git-format-patch follows, which demonstrates the problem:
>
>
> >From 3440baaed3b21138f6fc8b80e03769e3903f9c11 Mon Sep 17 00:00:00 2001
> From: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>
> Date: Wed, 7 Nov 2007 22:51:44 -0800
> Subject: [PATCH] hrtimer: Add timer back to pending list if it was reactivated and has already expired again.
>
> This avoids problems with timer hardware that does not respond to timers set in the past.
>
> Signed-off-by: Brian Swetland <swetland@android.com>
> ---
> kernel/hrtimer.c | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
> index 22a2514..7c60769 100644
> --- a/kernel/hrtimer.c
> +++ b/kernel/hrtimer.c
> @@ -1149,8 +1149,14 @@ static void run_hrtimer_softirq(struct softirq_action *h)
> * If the timer was rearmed on another CPU, reprogram
> * the event device.
> */
> - if (timer->base->first == &timer->node)
> - hrtimer_reprogram(timer, timer->base);
> + if (timer->base->first == &timer->node) {
> + if(hrtimer_reprogram(timer, timer->base)) {
> + __remove_hrtimer(timer, timer->base,
> + HRTIMER_STATE_PENDING, 0);
> + list_add_tail(&timer->cb_entry,
> + &cpu_base->cb_pending);
> + }
> + }
> }
> }
> spin_unlock_irq(&cpu_base->lock);