> * One email per commit [1].  For each reference change, the script
>   first emits one email summarizing the reference change (including
>   one-line summaries of the new commits), then emits a separate email
>   for each new commit that was introduced, including patches.

I have a dirty hack to do that on my private repositories (instead of
sending mail on receive, the script runs as a cron job, does a "git
fetch" on each repo on my machine, and sends me patches for new commits
with "git send-email"). I had several problems with it:

* Binary content was sometimes embedded in the patch. It's cool that
  "git send-email" can base64-encode content when I send a patch to
  someone, but it's counter-productive when used for code review. So, I
  used "git format-patch --no-binary".

* Even with that, I sometimes had overly long lines (e.g. non-text files
  that were shown as a one long line, I don't remember exactly the
  use-case, probably postscript files or so) that were confusing my
  mailer. So, I added

    # Truncate long lines
    perl -pi -e 's/^(.{500}).*/$1 [...]/' $patches

  to my script to truncate them.

You probably want to test these cases, and allow (configurably) the user
to do some cleanup on patches before they are sent.

Matthieu Moy
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to