[email protected] writes:
> * 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
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
