While it makes no sense to map some email address to an empty one, doing

things the other way around can be useful. For example when using

filter-branch with an env-filter that employs a mailmap to fix up an

import that created such broken commits with empty email addresses.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>

---

 mailmap.c |    9 +++++----

 1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/mailmap.c b/mailmap.c

index f12bb45..654c629 100644

--- a/mailmap.c

+++ b/mailmap.c

@@ -90,7 +90,8 @@ static void add_mapping(struct string_list *map,

 		 old_name, old_email, new_name, new_email);

 }
-static char *parse_name_and_email(char *buffer, char **name, char **email)

+static char *parse_name_and_email(char *buffer, char **name,

+		char **email, int allow_empty_email)

 {

 	char *left, *right, *nstart, *nend;

 	*name = *email = 0;

@@ -99,7 +100,7 @@ static char *parse_name_and_email(char *buffer, char **name, char **email)

 		return NULL;

 	if ((right = strchr(left+1, '>')) == NULL)

 		return NULL;

-	if (left+1 == right)

+	if (!allow_empty_email && (left+1 == right))

 		return NULL;
 	/* remove whitespace from beginning and end of name */

@@ -150,8 +151,8 @@ static int read_single_mailmap(struct string_list *map, const char *filename, ch

 			}

 			continue;

 		}

-		if ((name2 = parse_name_and_email(buffer, &name1, &email1)) != NULL)

-			parse_name_and_email(name2, &name2, &email2);

+		if ((name2 = parse_name_and_email(buffer, &name1, &email1, 0)) != NULL)

+			parse_name_and_email(name2, &name2, &email2, 1);
 		if (email1)

 			add_mapping(map, name1, email1, name2, email2);

--

1.6.2.1.425.ga9a94

--

The umlaut (ö) in my name is broken in the commit that made it into

git.git --> 5288dd58356e53d61e2b3804fc7d8d23c3a46ab3
Last time this happened when I used format-patch -s instead of commit -s

IIRC. But since then, I pay attention to do the sign-off via commit -s,

yet my name is broken again. What did I do wrong this time?
Björn

--

The mail you sent that presumably became 5288dd58 looks fine (both the

From and body are properly marked as iso8859-1), and "git am" applies it

correctly here. I wonder if Junio did something unusual while applying.
-Peff

--

Hm, ok, so I take it that it wasn't me who broke things. Then I'm

already happy. I don't care much about my name being messed up, but just

wanted to make sure that it wasn't my fault.
Thanks,

Björn

--

I don't see nothing wrong in your mails. It appears to be a double

conversion to UTF-8 between the mail and the commit.
But I always use format-patch -s without problems, what was your

problem with format-patch?
Santi

--

I don't recall the exact problem, and I can't find the mails anymore,

the IIRC it was something about Content-type being generated from the

original commit message, and only afterwards the sign-off line got

added, or something like that. That causes the Content-type to say

ascii, although the sign-off had UTF-8 in it. Or something like that.

Might very well have been fixed since then (it was almost 2 years ago

that I hit that bug IIRC), but it made me stick to commit -s ;-)
Björn

--

Uf! half an eternity in git scale ;-)
Santi

--