Author map in TOML is problematic

[JohnPeacockMessageSystems]

Having the author mapping file use the TOML syntax is a problem because pretty much by definition, most people have spaces in their real name. Some people even have singlequote characters in their last name. Consequently, it's sometimes really really hard to correctly write a line to convert a perfectly legal Mercurial username into a perfectly legal Git username via TOML.

This was the suggested syntax that was proffered for the problematic user

'"Devon H. O'Dell <[email protected]>"' = 'My <[email protected]>'

The Mercurial username has double quotes embedded (which was wrong but not illegal). But how can I use single-quotes around the key string with an embedded single quote in his last name?

While writing this bug report, I finally figured out the correct syntax, which was

"\"Devon H. O'Dell <[email protected]>\"" = "Devon H. O'Dell <[email protected]>"

but that was non-obvious to say the least. Primarily this issue was difficult because TOML is not the best choice for data that frequently contains whitespace.

[kilork]

That sounds reasonable. We probably should support multiple formats for config and authors. Or at least better document this case.

In my case I have to synchronise huge repository daily during long going migration with multiple typos and corrections in the author's table. Because I also need to gather feedback from persons, mentioned in this table, I have no hope they all would provide me correctly escaped data and I did not want to do it by myself. Instead I created markdown document AUTHORS.md, which everyone can correct just as any other normal markdown table. After this I wrote small rust utility to sync it with toml representation.

[JohnPeacockMessageSystems]

Thanks for considering this enhancement. I'm trying to migrate a repo that was originally in CVS, migrated to Subversion, migrated to Mercurial, split into 3 repos in Mercurial, and finally merged back into a single Mercurial repo. I have a lot of sin that I need to answer for in the migration to git...

[kilork]

In my repo we also had all possible sins, but of course we can discover new cases. It is good, because it gives me new input and possibility to return again to this project, which is in my rank currently on 3rd place, but was really my first project, which is useful not only for me. So many thanks for your feedback, I really appreciate it.

I currently have only one repo for my tests, because I cannot take a repo from my last work place. I am using it to check regressions after minor updates I am doing time to time for this project. But it is not very representative and relatively small. Previously with my huge repo I already discovered, that our performance limited not by mercurial parse, but much more by git import itself, which of course I just cannot improve. That means it is more important to focus on usability and better documentation.