[+Cc people involved with this function] Christoph Miebach <christoph.miebach@xxxxxx> writes: > > git commit --author="Michał Tz <name_1911@xxxxxxxx>" modified.file -m > > "Test" > > > > git format-patch -o patches origin > > > > Now, the patch seems to have the address right, see [1] > > > > git send-email --to MYOWN.ADDRESS@xxxxxxxx --suppress-cc=author > > patches/0001-Test.patch > > > > But checking my inbox now shows an email starting with: > > From: Michał Tz <name 1911@xxxxxxxx> > > Removing this line > s/_/ /g; > here > https://github.com/git/git/blob/master/git-send-email.perl#L867 > > Solves this problem for me. But I really don't have any clue, what > kind of side effects this modification on "sub unquote_rfc2047" might > have. It would prevent spaces from being decoded correctly if the encoding program chooses to make the '_'. git-format-patch does not actually do this, see the big comment around pretty.c:304. I think this patch would be a better match for what RFC2047 specifies. On the one hand it avoids substituting _ outside of encodings, but OTOH it also handles more than one encoded-word. It still does not handle the case where there are several encoded-words of *different* encodings, but who would do such a crazy thing? diff --git i/git-send-email.perl w/git-send-email.perl index ef30c55..88c4758 100755 --- i/git-send-email.perl +++ w/git-send-email.perl @@ -862,11 +862,13 @@ sub make_message_id { sub unquote_rfc2047 { local ($_) = @_; my $encoding; - if (s/=\?([^?]+)\?q\?(.*)\?=/$2/g) { + s{=\?([^?]+)\?q\?(.*)\?=}{ $encoding = $1; - s/_/ /g; - s/=([0-9A-F]{2})/chr(hex($1))/eg; - } + my $e = $2; + $e =~ s/_/ /g; + $e =~ s/=([0-9A-F]{2})/chr(hex($1))/eg; + $e; + }eg; return wantarray ? ($_, $encoding) : $_; } -- Thomas Rast trast@{inf,student}.ethz.ch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html