Address headers encoding

[rhertzog]

Please merge this branch to fix issue #33 with invalid encoding of email addresses.

[mhagger]

Cool, thanks for the patches!

I was looking into a fix for the encoding problem myself so I was able to give pretty detailed comments. If you fix the line-length problem then I will definitely accept patches 1 and 3. Regarding patch 2, I am willing to be convinced. Is patch 2 necessary for the other two patches? If not, please rebase it to the end of the patch series so that it doesn't hold the other two patches hostage.

Please also sign off your patches in the Git style, as I have to sign them off when I submit the change to Git and I have to be more careful to do things by the book :-)

[rhertzog]

Thanks for the thorough review, I'll update my branch. The second patch was "only needed" to be able to update the test data, I can certainly move it at the end.

[rhertzog]

I think that I have taken care of all your comments. I left the "git log using user config" issue aside and just fixed the test suite to work in a clean environment (mimicking what t/test-env was already doing).

[rhertzog]

Here's another update taking care of your latest comments.

[mhagger]

I just merged and pushed your changes. Thanks!

[moy]

Some more thoughts about the "use plumbing" Vs "disable config" question: After thinking a bit more about it, I think it makes sense to run "git log" (not "git rev-list") to generate the body of messages and possibly to disable the user's configuration in this case.

Using plumbing is the right thing when the output is meant for machine consumption. But in our case, the output of "git log" is not parsed, but only used to create a message that is meant to be read by the user. Using "git log" is what makes it simple to have multimailhook.logOpts, which accepts exactly what "git log" accepts. Arguably, git-multimail taking into account the repository's configuration (log.decorate) is a good thing. It's not a good idea to follow the user's log.decorate for a shared repository though.

[mhagger]

Your comments about using "git log" rather than "git rev-list" sound reasonable.

ISTM that there are a few distinct ways of using git-multimail that we should try to keep in mind when considering configuration questions:

• Central, server-side repo controlled by one human user (e.g., pull request model) or one unix user (e.g., gitolite's setup, where the repo is always accessed by a uid "git"). In such a case the administrator of the repository can set the configuration to get the git-multimail output that he/she wants.
• Central repo accessed via multiple uids (e.g., an SSH setup which each user accesses using his/her own login). In this case the git config depends on which user happens to have done the push, because the user's ~/.gitconfig comes into play.
• Local repo for which the user wants to generate emails to him/herself (@moy, this is your use case, right?). In this case, the user can configure git the way he/she wants, but the config doesn't just affect git-multimail (and therefore the user does not necessarily want to optimize his/her config for git-multimail).

Maybe we should make it easier for the user to configure (via the hook script or within the repo configuration) which other Git configs should be read/ignored by git-multimail. This could currently be done by creating a mock HOME directory and setting it in the hook script via $HOME, and setting $GIT_CONFIG_NOSYSTEM to avoid reading /etc/gitconfig, but that's kindof cumbersome.