[PATCH] Mailmap: Allow empty email addresses to be mapped

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 <redacted>
---
 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

On 2009.03.31 17:30:39 +0200, Björn Steinbrink wrote:

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 <redacted>

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

2009/4/6 Björn Steinbrink [off-list ref]:

On 2009.03.31 17:30:39 +0200, Björn Steinbrink wrote:

quoted

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 <redacted>

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?

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

On 2009.04.06 14:46:43 +0200, Santi Béjar wrote:

2009/4/6 Björn Steinbrink [off-list ref]:

quoted

On 2009.03.31 17:30:39 +0200, Björn Steinbrink wrote:

quoted

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 <redacted>

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?

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?

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

2009/4/6 Björn Steinbrink [off-list ref]:

On 2009.04.06 14:46:43 +0200, Santi Béjar wrote:

quoted

2009/4/6 Björn Steinbrink [off-list ref]:

quoted

On 2009.03.31 17:30:39 +0200, Björn Steinbrink wrote:

quoted

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 <redacted>

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?

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?

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

Yes, it is fixed (at least what you described).

(it was almost 2 years ago
that I hit that bug IIRC),

Uf! half an eternity in git scale ;-)

Santi

On Mon, Apr 06, 2009 at 01:46:18PM +0200, Björn Steinbrink wrote:

On 2009.03.31 17:30:39 +0200, Björn Steinbrink wrote:

quoted

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 <redacted>

The umlaut (ö) in my name is broken in the commit that made it into
git.git --> 5288dd58356e53d61e2b3804fc7d8d23c3a46ab3

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

On 2009.04.06 12:47:33 -0400, Jeff King wrote:

On Mon, Apr 06, 2009 at 01:46:18PM +0200, Björn Steinbrink wrote:

quoted

On 2009.03.31 17:30:39 +0200, Björn Steinbrink wrote:

quoted

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 <redacted>

The umlaut (ö) in my name is broken in the commit that made it into
git.git --> 5288dd58356e53d61e2b3804fc7d8d23c3a46ab3

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

quoted

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.

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