When designing parsers, the rule is to be strict in what you emit and liberal in what you accept.
Surely. But I'm not writing a parser, I'm just importing the patches with all the mercurial metadata that comes with an export. If it's not a mercurial patch, then I have to take a completely different path of generating that metadata and using different tools to apply and commit.
I think that's also a good rule when it comes to handling patches in an open source project. Creating a script to import a git patch series would be a one-time process, and it lowers to bar of entry for potential contributors.
So if we were on github and someone wanted to send raw diffs against random non-tip points in the tree to the mailing list, someone should take the time and just create pull requests out of them all? I think if we were on github, such a request would be met with "dude, just create a pull request!"
Most open source projects, especially ones run and funded by volunteers, have contribution guidelines to make it easy on everyone. All the required mercurial-fu is documented on the process page and I expect we've spent more time discussing it than it takes to generate patches :)
But I'll suck it up and learn to push my patches through Mercurial. I'm still going to use git and hg-git for my development though, because the workflow is so ingrained.
As long as they 'hg import' cleanly to the main repo, that's all I care about. Thanks!
--Dan