That said, I could just fake it, since it's apples to oranges anyway. As long as it's unique for each patch, it should serve for the purpose that you describe, yah?
Yes.
That would be fairly easy to add; in the git-patch-to-hg-patch script, hash the original email message (which includes a time/date string) and then emit it as part of the body.
The hash identifies what you sent, not when you sent it. The two are the same to me, but not to you, so the timestamp is fine with me, but I think the hash is the right thing to do. Well, actually, I think the right thing to do is use our tool, but, you know.
What is the point of writing the raw string into the file before we open it? That said, the above should be this for consistency:
Well, it works. The string does make it into the log file.
Sure, but that wasn't the question, the question was: "why?"
It's not a log message because that would end up on the console as well, and we should not unilaterally spam that line at every launch (as that could preclude chirpc from being usable in command pipelines).
Logging at DEBUG level seems appropriate, regardless of where it ends up. So far, you're still relying on the stdout intervention for generating debug.log on Win32, so logging it, having it go to the console, and thus ending up there is appropriate at the moment. When you add a FileHandler for debug.log, you can set that to DEBUG, let the console handler default to INFO, and then you won't see it on the console.
--Dan