Apparently author names that don't match the "Name <email>" format are imported ok by git but the resulting repo has some sort of problems, although I don't have any details on the nature of the problems.
Currently we grab both the value of the author cert and the key that signed the author cert. The value is to be used as the git author and the key name is to be used as the git committer. Both of these are looked up in the author map to see if the user has specified replacement values that should be used in the exported data. If no replacements have been specified both the author and committer are checked to see if they contain '<' and '>' characters and if neither are present they are wrapped in these characters. This produces names that lack the "Name " before the "<email>" and apparently causes problems.
If I remember right, there was once some interest in an option to require these values to exist in the author map file avoiding any automated doctoring of the author and committer values or failing if unmapped values exist. Having this might be one way to deal with the above problem. Reasonable suggestions for what to call such an option are welcome. I can't think of anything catchy.
Another solution is to do more comprehensive checks on the author and committer values if they don't exist in the author map file, such as the following:
If the value doesn't contain < and > characters
- replace "foo" with "foo <foo>" if no "@" character exists
- replace "address@hidden" with "foo <address@hidden>"
If the value begins with '<' and ends with '>'
- replace "<foo>" with "foo <foo>" if no "@" character exists
- replace "<address@hidden>" with "foo <address@hidden>"
Maybe these adjustments should be done in a lua hook that can be customized if needed.
Finally, ensure that the resulting values match a valid git name regex, something like "^[^<]* <[^>]*>$" and fail if they don't. This could check values coming from the author map in addition to values constructed by the replacements above or could apply only to the automated replacements. Again, maybe this regex should come from a lua hook or perhaps the entire validity check should be done by a lua hook, either of which can be customized.