[PATCH] post-receive-email: explicitly set Content-Type header

[PATCH] post-receive-email: explicitly set Content-Type header

[Alexey Shumkin]

Some email clients (e.g. claws-mail) incorrectly display
message body when there is no Content-Type header and charset
explicitly defined.
So, set explicitly Content-Type headrer and charset
can be defined with hooks.emailcharset config variable.

Signed-off-by: Alexey Shumkin <zapped@mail.ru>
---
 contrib/hooks/post-receive-email |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 21989fc..64d7c2f 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -60,6 +60,8 @@
 #   email body. If not specified, there is no limit.
 #   Lines beyond the limit are suppressed and counted, and a final
 #   line is added indicating the number of suppressed lines.
+# hooks.emailcharset
+#   The charset used in Content-Type header. UTF-8, if not specified.
 #
 # Notes
 # -----
@@ -229,6 +231,7 @@ generate_email_header()
 	cat <<-EOF
 	To: $recipients
 	Subject: ${emailprefix}$projectdesc $refname_type $short_refname ${change_type}d. $describe
+	Content-Type: text/plain; charset=$emailcharset
 	X-Git-Refname: $refname
 	X-Git-Reftype: $refname_type
 	X-Git-Oldrev: $oldrev
@@ -723,6 +726,7 @@ envelopesender=$(git config hooks.envelopesender)
 emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
 custom_showrev=$(git config hooks.showrev)
 maxlines=$(git config hooks.emailmaxlines)
+emailcharset=$(git config hooks.emailcharset || echo 'UTF-8')
 
 # --- Main loop
 # Allow dual mode: run from the command line just like the update hook, or
-- 
1.7.6.3.4.gf71f

[PATCH v2] post-receive-email: explicitly set Content-Type header

[Alexey Shumkin]

Some email clients (e.g. claws-mail) incorrectly display
message body when there is no Content-Type header and charset
explicitly defined.
So, set explicitly Content-Type header and charset
can be defined with hooks.emailcharset config variable.

Signed-off-by: Alexey Shumkin <zapped@mail.ru>
---
 [resent: Fixed typo in commit message]

 contrib/hooks/post-receive-email |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 21989fc..64d7c2f 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -60,6 +60,8 @@
 #   email body. If not specified, there is no limit.
 #   Lines beyond the limit are suppressed and counted, and a final
 #   line is added indicating the number of suppressed lines.
+# hooks.emailcharset
+#   The charset used in Content-Type header. UTF-8, if not specified.
 #
 # Notes
 # -----
@@ -229,6 +231,7 @@ generate_email_header()
 	cat <<-EOF
 	To: $recipients
 	Subject: ${emailprefix}$projectdesc $refname_type $short_refname ${change_type}d. $describe
+	Content-Type: text/plain; charset=$emailcharset
 	X-Git-Refname: $refname
 	X-Git-Reftype: $refname_type
 	X-Git-Oldrev: $oldrev
@@ -723,6 +726,7 @@ envelopesender=$(git config hooks.envelopesender)
 emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
 custom_showrev=$(git config hooks.showrev)
 maxlines=$(git config hooks.emailmaxlines)
+emailcharset=$(git config hooks.emailcharset || echo 'UTF-8')
 
 # --- Main loop
 # Allow dual mode: run from the command line just like the update hook, or
-- 
1.7.6.3.4.gf71f

Re: [PATCH v2] post-receive-email: explicitly set Content-Type header

[Johannes Sixt]

Am 9/20/2011 10:07, schrieb Alexey Shumkin:
> Some email clients (e.g. claws-mail) incorrectly display
> message body when there is no Content-Type header and charset
> explicitly defined.
> So, set explicitly Content-Type header and charset
> can be defined with hooks.emailcharset config variable.

Please write full sentences with complete punctuation and capitalization.
Perhaps you meant to say:

  Some email clients (e.g. claws-mail) display the message body
  incorrectly when the charset is not defined explicitly in a
  Content-Type header. Insert a Content-Type header in the message.

  The charset can be defined with the config variable
  hooks.emailcharset.

> +# hooks.emailcharset
> +#   The charset used in Content-Type header. UTF-8, if not specified.

How can you be sure that the output produced by git log etc. that are used
in the script are in the encoding specified by this variable? IOW,
wouldn't log.outputencoding be the better choice to use in the
Content-Type header?

-- Hannes

Re: [PATCH v2] post-receive-email: explicitly set Content-Type header

[Shumkin Alexey]

[ resent to mailing list ]
On Tue, Sep 20, 2011 at 11:32:54AM +0200, Johannes Sixt wrote:
> Am 9/20/2011 10:07, schrieb Alexey Shumkin:
> > Some email clients (e.g. claws-mail) incorrectly display
> > message body when there is no Content-Type header and charset
> > explicitly defined.
> > So, set explicitly Content-Type header and charset
> > can be defined with hooks.emailcharset config variable.
> 
> Please write full sentences with complete punctuation and capitalization.
> Perhaps you meant to say:
> 
>   Some email clients (e.g. claws-mail) display the message body
>   incorrectly when the charset is not defined explicitly in a
>   Content-Type header. Insert a Content-Type header in the message.
> 
>   The charset can be defined with the config variable
>   hooks.emailcharset.
Thanks for the correction. English is not my native language
(although it is not for you, too, I guess :) ).
I read it and take on ear fine but I have no enough practice to write on it.

> > +# hooks.emailcharset
> > +#   The charset used in Content-Type header. UTF-8, if not
> > specified.
> 
> How can you be sure that the output produced by git log etc. that are
> used in the script are in the encoding specified by this variable?
> IOW, wouldn't log.outputencoding be the better choice to use in the
> Content-Type header?
Yes, you're right, we cannot be sure in UTF-8 encoding of output
and using i18n.logoutputencoding would be a better choice
instead of new config variable.

But at the present
1. post-send-mail uses description file of a repo
2. gitweb also uses this file and AFAIK it assumes one to be in UTF-8
  (I do not know whether it can be changed there but I tested gitweb once long
    time ago)
3. So if i18n.logoutputencoding is not UTF-8 we get a message composed
	with mixed encodings. This fact oblidge us to encode headers
	(as quoted printable at least) and synchronize body message that contain
	repo description (in UTF-8) and diffstat (in i18n.logoutputencoding).
	This is a more complicated task for a shell script
	than just specifying Content-Type header (may be git-send-email suits here?)

So that was a quick solution for me :)

Re: [PATCH v2] post-receive-email: explicitly set Content-Type header

[Johannes Sixt]

Am 9/20/2011 12:42, schrieb Shumkin Alexey:
> On Tue, Sep 20, 2011 at 11:32:54AM +0200, Johannes Sixt wrote:
>> Am 9/20/2011 10:07, schrieb Alexey Shumkin:
>>> +# hooks.emailcharset
>>> +#   The charset used in Content-Type header. UTF-8, if not
>>> specified.
>>
>> How can you be sure that the output produced by git log etc. that are
>> used in the script are in the encoding specified by this variable?
>> IOW, wouldn't log.outputencoding be the better choice to use in the
>> Content-Type header?
> Yes, you're right, we cannot be sure in UTF-8 encoding of output
> and using i18n.logoutputencoding would be a better choice
> instead of new config variable.
> 
> But at the present
> 1. post-send-mail uses description file of a repo
> 2. gitweb also uses this file and AFAIK it assumes one to be in UTF-8
>   (I do not know whether it can be changed there but I tested gitweb once long
>     time ago)
> 3. So if i18n.logoutputencoding is not UTF-8 we get a message composed
> 	with mixed encodings. This fact oblidge us to encode headers
> 	(as quoted printable at least) and synchronize body message that contain
> 	repo description (in UTF-8) and diffstat (in i18n.logoutputencoding).
> 	This is a more complicated task for a shell script
> 	than just specifying Content-Type header (may be git-send-email suits here?)

In this case, it may make sense to have a separate setting, but you should
call git like this:

   git -c "i18n.logoutputencoding=$emailcharset" show ...
   git -c "i18n.logoutputencoding=$emailcharset" rev-list --pretty ...

-- Hannes

Re: [PATCH v2] post-receive-email: explicitly set Content-Type header

[Jakub Narebski]

Shumkin Alexey <zapped@mail.ru> writes:
> [ resent to mailing list ]
> On Tue, Sep 20, 2011 at 11:32:54AM +0200, Johannes Sixt wrote:
> > Am 9/20/2011 10:07, schrieb Alexey Shumkin:
[...]
> > > +# hooks.emailcharset
> > > +#   The charset used in Content-Type header. UTF-8, if not
> > > specified.
> > 
> > How can you be sure that the output produced by git log etc. that are
> > used in the script are in the encoding specified by this variable?
> > IOW, wouldn't log.outputencoding be the better choice to use in the
> > Content-Type header?
>
> Yes, you're right, we cannot be sure in UTF-8 encoding of output
> and using i18n.logoutputencoding would be a better choice
> instead of new config variable.
> 
> But at the present
> 1. post-send-mail uses description file of a repo
> 2. gitweb also uses this file and AFAIK it assumes one to be in UTF-8
>   (I do not know whether it can be changed there but I tested gitweb once long
>     time ago)

I have thought that gitweb uses '--encoding=utf8' explicitly, but as I
have checked it uses this only for git-format-patch invocation in
'patch' / 'patches' views.  Should be fixed.

-- 
Jakub Narębski

Re: [PATCH v2] post-receive-email: explicitly set Content-Type header

[Jonathan Nieder]

Johannes Sixt wrote:
> Am 9/20/2011 12:42, schrieb Shumkin Alexey:

>> 1. post-send-mail uses description file of a repo
>> 2. gitweb also uses this file and AFAIK it assumes one to be in UTF-8
>>   (I do not know whether it can be changed there but I tested gitweb once long
>>     time ago)
>> 3. So if i18n.logoutputencoding is not UTF-8 we get a message composed
>> 	with mixed encodings. This fact oblidge us to encode headers
>> 	(as quoted printable at least) and synchronize body message that contain
>> 	repo description (in UTF-8) and diffstat (in i18n.logoutputencoding).
[...]
> In this case, it may make sense to have a separate setting, but you should
> call git like this:
>
>    git -c "i18n.logoutputencoding=$emailcharset" show ...
>    git -c "i18n.logoutputencoding=$emailcharset" rev-list --pretty ...

Something like this, I suppose?

This teaches post-receive-email to use plumbing where possible and to
explicitly declare what encoding it expects output to use.  Completely
untested --- basic sanity checking, testing, and tweaks to allow
overriding the choice of encoding left as an exercise to the reader.

Based on patches by Gerrit Pape and Jeff King and advice from Johannes
Sixt.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
More background:
http://thread.gmane.org/gmane.comp.version-control.git/124350/focus=124355

 contrib/hooks/post-receive-email |   15 +++++++++------
 1 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index ba077c13..bc603b02 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -234,6 +234,9 @@ generate_email_header()
 	cat <<-EOF
 	To: $recipients
 	Subject: ${emailprefix}$projectdesc $refname_type $short_refname ${change_type}d. $describe
+	MIME-Version: 1.0
+	Content-Type: text/plain; charset=utf-8
+	Content-Transfer-Encoding: 8bit
 	X-Git-Refname: $refname
 	X-Git-Reftype: $refname_type
 	X-Git-Oldrev: $oldrev
@@ -462,7 +465,7 @@ generate_delete_branch_email()
 	echo "       was  $oldrev"
 	echo ""
 	echo $LOGEND
-	git show -s --pretty=oneline $oldrev
+	git diff-tree --encoding=UTF-8 -s --pretty=oneline $oldrev
 	echo $LOGEND
 }
 
@@ -538,11 +541,11 @@ generate_atag_email()
 		# performed on them
 		if [ -n "$prevtag" ]; then
 			# Show changes since the previous release
-			git rev-list --pretty=short "$prevtag..$newrev" | git shortlog
+			git shortlog --encoding=UTF-8 "$prevtag..$newrev"
 		else
 			# No previous tag, show all the changes since time
 			# began
-			git rev-list --pretty=short $newrev | git shortlog
+			git shortlog --encoding=UTF-8 "$newrev"
 		fi
 		;;
 	*)
@@ -562,7 +565,7 @@ generate_delete_atag_email()
 	echo "       was  $oldrev"
 	echo ""
 	echo $LOGEND
-	git show -s --pretty=oneline $oldrev
+	git diff-tree --encoding=UTF-8 -s --pretty=oneline $oldrev
 	echo $LOGEND
 }
 
@@ -608,7 +611,7 @@ generate_general_email()
 	echo ""
 	if [ "$newrev_type" = "commit" ]; then
 		echo $LOGBEGIN
-		git show --no-color --root -s --pretty=medium $newrev
+		git diff-tree --encoding=UTF-8 --root -s --pretty=oneline $newrev
 		echo $LOGEND
 	else
 		# What can we do here?  The tag marks an object that is not
@@ -627,7 +630,7 @@ generate_delete_general_email()
 	echo "       was  $oldrev"
 	echo ""
 	echo $LOGEND
-	git show -s --pretty=oneline $oldrev
+	git diff-tree --encoding=UTF-8 -s --pretty=oneline $oldrev
 	echo $LOGEND
 }
 
-- 
1.7.7.rc1

Re: [PATCH v2] post-receive-email: explicitly set Content-Type header

[Alexey Shumkin]

> Johannes Sixt wrote:
> > Am 9/20/2011 12:42, schrieb Shumkin Alexey:
> 
> >> 1. post-send-mail uses description file of a repo
> >> 2. gitweb also uses this file and AFAIK it assumes one to be in
> >> UTF-8 (I do not know whether it can be changed there but I tested
> >> gitweb once long time ago)
> >> 3. So if i18n.logoutputencoding is not UTF-8 we get a message
> >> composed with mixed encodings. This fact oblidge us to encode
> >> headers (as quoted printable at least) and synchronize body
> >> message that contain repo description (in UTF-8) and diffstat (in
> >> i18n.logoutputencoding).
> [...]
> > In this case, it may make sense to have a separate setting, but you
> > should call git like this:
> >
> >    git -c "i18n.logoutputencoding=$emailcharset" show ...
> >    git -c "i18n.logoutputencoding=$emailcharset" rev-list
> > --pretty ...
> 
> Something like this, I suppose?
> 
> This teaches post-receive-email to use plumbing where possible and to
> explicitly declare what encoding it expects output to use.  Completely
> untested --- basic sanity checking, testing, and tweaks to allow
> overriding the choice of encoding left as an exercise to the reader.
> 
> Based on patches by Gerrit Pape and Jeff King and advice from Johannes
> Sixt.
> 
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> More background:
> http://thread.gmane.org/gmane.comp.version-control.git/124350/focus=124355
> 
>  contrib/hooks/post-receive-email |   15 +++++++++------
>  1 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/contrib/hooks/post-receive-email
> b/contrib/hooks/post-receive-email index ba077c13..bc603b02 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -234,6 +234,9 @@ generate_email_header()
>  	cat <<-EOF
>  	To: $recipients
>  	Subject: ${emailprefix}$projectdesc $refname_type
> $short_refname ${change_type}d. $describe
> +	MIME-Version: 1.0
> +	Content-Type: text/plain; charset=utf-8
> +	Content-Transfer-Encoding: 8bit
>  	X-Git-Refname: $refname
>  	X-Git-Reftype: $refname_type
>  	X-Git-Oldrev: $oldrev
> @@ -462,7 +465,7 @@ generate_delete_branch_email()
>  	echo "       was  $oldrev"
>  	echo ""
>  	echo $LOGEND
> -	git show -s --pretty=oneline $oldrev
> +	git diff-tree --encoding=UTF-8 -s --pretty=oneline $oldrev
>  	echo $LOGEND
>  }
>  
> @@ -538,11 +541,11 @@ generate_atag_email()
>  		# performed on them
>  		if [ -n "$prevtag" ]; then
>  			# Show changes since the previous release
> -			git rev-list --pretty=short
> "$prevtag..$newrev" | git shortlog
> +			git shortlog --encoding=UTF-8
> "$prevtag..$newrev" else
>  			# No previous tag, show all the changes
> since time # began
> -			git rev-list --pretty=short $newrev | git
> shortlog
> +			git shortlog --encoding=UTF-8 "$newrev"
>  		fi
>  		;;
>  	*)
> @@ -562,7 +565,7 @@ generate_delete_atag_email()
>  	echo "       was  $oldrev"
>  	echo ""
>  	echo $LOGEND
> -	git show -s --pretty=oneline $oldrev
> +	git diff-tree --encoding=UTF-8 -s --pretty=oneline $oldrev
>  	echo $LOGEND
>  }
>  
> @@ -608,7 +611,7 @@ generate_general_email()
>  	echo ""
>  	if [ "$newrev_type" = "commit" ]; then
>  		echo $LOGBEGIN
> -		git show --no-color --root -s --pretty=medium $newrev
> +		git diff-tree --encoding=UTF-8 --root -s
> --pretty=oneline $newrev echo $LOGEND
>  	else
>  		# What can we do here?  The tag marks an object that
> is not @@ -627,7 +630,7 @@ generate_delete_general_email()
>  	echo "       was  $oldrev"
>  	echo ""
>  	echo $LOGEND
> -	git show -s --pretty=oneline $oldrev
> +	git diff-tree --encoding=UTF-8 -s --pretty=oneline $oldrev
>  	echo $LOGEND
>  }
>  

As I understand, this patches make email message with explicitly set
Content-Type header (it's ok) and UTF-8 encoding (that is a subject
to discuss).
My proposition was in to send email message in explicitly defined
custom encoding. Why? In development process under Windows non-UTF-8
encoding is used (cp1251 in my case). So, filenames have this encoding,
and as we know Git stores their names as is - in cp1251 - without a
conversion. And filenames are also used in diff-stat (with
core.quotepath= false, BTW, I did not take into account this config)
without any conversion. So if we'll make all text in UTF-8 but
filenames are still non-UTF-8, email would look corrupted.

Re: [PATCH v2] post-receive-email: explicitly set Content-Type header

[Jonathan Nieder]

Alexey Shumkin wrote:

> In development process under Windows non-UTF-8
> encoding is used (cp1251 in my case). So, filenames have this encoding,
> and as we know Git stores their names as is - in cp1251 - without a
> conversion. And filenames are also used in diff-stat (with
> core.quotepath= false

Yes, when a person sets [core] quotepath to false, I think it's fair to
assume for now that the filenames are in the same encoding as
everything else (whether that's UTF-8 or something else).  Maybe it
would be possible in a separate patch to add a configurable list of
encodings to try out when formatting paths for display.

Jonathan

[PATCH v3] post-receive-email: explicitly set Content-Type header

[Alexey Shumkin]

Some email clients (e.g. claws-mail) incorrectly display
message body when there is no Content-Type header and charset
explicitly defined.
So, set explicitly Content-Type header. Its charset
can be defined with hooks.emailcharset config variable.

NB: This above-mentioned charset may differ from i18n.logOutputEncoding,
because e.g. gitweb expects (for now) i18n.logOutputEncoding set to UTF-8
to display logs correctly.

Also, introduce hooks.gitopts config variable
with the default '-c core.quotepath=false'.
This takes into account that we want to see pretty email-message
with well-looking messages and list of changed filenames.
And usually non-ASCII filenames are in the same
encoding that commit messages are.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
---
 contrib/hooks/post-receive-email |   43 ++++++++++++++++++++++++++-----------
 1 files changed, 30 insertions(+), 13 deletions(-)

diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index ba077c1..913be89 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -65,6 +65,14 @@
 #   Default is "--stat --summary --find-copies-harder". Add -p to those
 #   options to include a unified diff of changes in addition to the usual
 #   summary output.
+# hooks.gitopts
+#   git options for the git diff-tree invocation that shows changes.
+#   Default is '-c core.quotepath=false' to be able to see non-ASCII filenames
+#   used in a project.
+# hooks.emailcharset
+#   The charset used in Content-Type header. UTF-8, if not specified.
+#   It can differ from i18n.logOutputEncoding (not to mess-up with gitweb
+#   which expects i18n.logOutputEncoding to be set to UTF-8)
 #
 # Notes
 # -----
@@ -234,6 +242,9 @@ generate_email_header()
 	cat <<-EOF
 	To: $recipients
 	Subject: ${emailprefix}$projectdesc $refname_type $short_refname ${change_type}d. $describe
+	MIME-Version: 1.0
+	Content-Type: text/plain; charset=$emailcharset
+	Content-Transfer-Encoding: 8bit
 	X-Git-Refname: $refname
 	X-Git-Reftype: $refname_type
 	X-Git-Oldrev: $oldrev
@@ -241,7 +252,7 @@ generate_email_header()
 
 	This is an automated email from the git hooks/post-receive script. It was
 	generated because a ref change was pushed to the repository containing
-	the project "$projectdesc".
+	the project "$projectdesc_e".
 
 	The $refname_type, $short_refname has been ${change_type}d
 	EOF
@@ -255,7 +266,7 @@ generate_email_footer()
 
 	hooks/post-receive
 	--${SPACE}
-	$projectdesc
+	$projectdesc_e
 	EOF
 }
 
@@ -451,7 +462,7 @@ generate_update_branch_email()
 	# non-fast-forward updates.
 	echo ""
 	echo "Summary of changes:"
-	git diff-tree $diffopts $oldrev..$newrev
+	git $gitopts diff-tree $diffopts $oldrev..$newrev
 }
 
 #
@@ -656,14 +667,15 @@ show_new_revisions()
 		revspec=$oldrev..$newrev
 	fi
 
+	revlistopts="-c i18n.logOutputEncoding=$emailcharset"
 	other_branches=$(git for-each-ref --format='%(refname)' refs/heads/ |
 	    grep -F -v $refname)
 	git rev-parse --not $other_branches |
 	if [ -z "$custom_showrev" ]
 	then
-		git rev-list --pretty --stdin $revspec
+		git $revlistopts rev-list --pretty --stdin $revspec
 	else
-		git rev-list --stdin $revspec |
+		git $revlistopts $rev-list --stdin $revspec |
 		while read onerev
 		do
 			eval $(printf "$custom_showrev" $onerev)
@@ -714,14 +726,6 @@ if [ -z "$GIT_DIR" ]; then
 	exit 1
 fi
 
-projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
-# Check if the description is unchanged from it's default, and shorten it to
-# a more manageable length if it is
-if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
-then
-	projectdesc="UNNAMED PROJECT"
-fi
-
 recipients=$(git config hooks.mailinglist)
 announcerecipients=$(git config hooks.announcelist)
 envelopesender=$(git config hooks.envelopesender)
@@ -730,6 +734,19 @@ custom_showrev=$(git config hooks.showrev)
 maxlines=$(git config hooks.emailmaxlines)
 diffopts=$(git config hooks.diffopts)
 : ${diffopts:="--stat --summary --find-copies-harder"}
+gitopts=$(git config hooks.gitopts || echo '-c core.quotepath=false')
+emailcharset=$(git config hooks.emailcharset || echo 'UTF-8')
+
+projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
+# Check if the description is unchanged from it's default, and shorten it to
+# a more manageable length if it is
+if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
+then
+	projectdesc="UNNAMED PROJECT"
+fi
+# Leave description in UTF-8 to be used in the Subject header
+# But convert it to an hooks.emailcharset encoding to be used in a message body
+projectdesc_e=$(echo $projectdesc | iconv -f UTF-8 -t $emailcharset 2>/dev/null)
 
 # --- Main loop
 # Allow dual mode: run from the command line just like the update hook, or
-- 
1.7.7.3.5.g55178

Re: [PATCH v3] post-receive-email: explicitly set Content-Type header

[Junio C Hamano]

Alexey Shumkin <alex.crezoff@gmail.com> writes:

> Some email clients (e.g. claws-mail) incorrectly display
> message body when there is no Content-Type header and charset
> explicitly defined.
> So, set explicitly Content-Type header. Its charset
> can be defined with hooks.emailcharset config variable.
>
> NB: This above-mentioned charset may differ from i18n.logOutputEncoding,
> because e.g. gitweb expects (for now) i18n.logOutputEncoding set to UTF-8
> to display logs correctly.
>
> Also, introduce hooks.gitopts config variable
> with the default '-c core.quotepath=false'.
> This takes into account that we want to see pretty email-message
> with well-looking messages and list of changed filenames.
> And usually non-ASCII filenames are in the same
> encoding that commit messages are.

(style) Why such an extremely ragged looking line-wrap of paragraphs?

> Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
> ---

In this space, please describe what happened during v1 and v2, and how is
this round different to help reviewers. Pointers to list archive, e.g.
http://thread.gmane.org/gmane.comp.version-control.git/181737, would be
helpful.

People involved in v1/v2 discussion are missing from the Cc: line. Please
do not give a false impression that you are hiding from them.

> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
> index ba077c1..913be89 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -65,6 +65,14 @@
>  #   Default is "--stat --summary --find-copies-harder". Add -p to those
>  #   options to include a unified diff of changes in addition to the usual
>  #   summary output.
> +# hooks.gitopts
> +#   git options for the git diff-tree invocation that shows changes.
> +#   Default is '-c core.quotepath=false' to be able to see non-ASCII filenames
> +#   used in a project.

We do not particularly appreciate a patch that does two unrelated things
("they are both related to post-receive-email" is not an argument).
Wouldn't this be useful even if the change to add hooks.emailcharset
turned out to be unwanted, or vice versa?

> +# hooks.emailcharset
> +#   The charset used in Content-Type header. UTF-8, if not specified.
> +#   It can differ from i18n.logOutputEncoding (not to mess-up with gitweb
> +#   which expects i18n.logOutputEncoding to be set to UTF-8)

Why "UTF-8" instead of "i18n.logoutputencoding" if not specified?

> @@ -234,6 +242,9 @@ generate_email_header()
>  	cat <<-EOF
>  	To: $recipients
>  	Subject: ${emailprefix}$projectdesc $refname_type $short_refname ${change_type}d. $describe
> +	MIME-Version: 1.0
> +	Content-Type: text/plain; charset=$emailcharset
> +	Content-Transfer-Encoding: 8bit
>  	X-Git-Refname: $refname
>  	X-Git-Reftype: $refname_type
>  	X-Git-Oldrev: $oldrev
> ...
> @@ -730,6 +734,19 @@ custom_showrev=$(git config hooks.showrev)
>  maxlines=$(git config hooks.emailmaxlines)
>  diffopts=$(git config hooks.diffopts)
>  : ${diffopts:="--stat --summary --find-copies-harder"}
> +gitopts=$(git config hooks.gitopts || echo '-c core.quotepath=false')
> +emailcharset=$(git config hooks.emailcharset || echo 'UTF-8')
> +
> +projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
> +# Check if the description is unchanged from it's default, and shorten it to
> +# a more manageable length if it is
> +if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
> +then
> +	projectdesc="UNNAMED PROJECT"
> +fi
> +# Leave description in UTF-8 to be used in the Subject header
> +# But convert it to an hooks.emailcharset encoding to be used in a message body
> +projectdesc_e=$(echo $projectdesc | iconv -f UTF-8 -t $emailcharset 2>/dev/null)

Hmm, this generates a piece of e-mail whose subject line is in UTF-8
(without B/Q quoting) and message body is in totally different encoding.
Is it what mailers really want to see?

It almost seems backwards; converting the payload to UTF-8 and always
sending UTF-8 would be a simpler approach, methinks.

Re: [PATCH v3] post-receive-email: explicitly set Content-Type header

[Alexey Shumkin]

> Alexey Shumkin <alex.crezoff@gmail.com> writes:
> 
> > Some email clients (e.g. claws-mail) incorrectly display
> > message body when there is no Content-Type header and charset
> > explicitly defined.
> > So, set explicitly Content-Type header. Its charset
> > can be defined with hooks.emailcharset config variable.
> >
> > NB: This above-mentioned charset may differ from
> > i18n.logOutputEncoding, because e.g. gitweb expects (for now)
> > i18n.logOutputEncoding set to UTF-8 to display logs correctly.
> >
> > Also, introduce hooks.gitopts config variable
> > with the default '-c core.quotepath=false'.
> > This takes into account that we want to see pretty email-message
> > with well-looking messages and list of changed filenames.
> > And usually non-ASCII filenames are in the same
> > encoding that commit messages are.
> 
> (style) Why such an extremely ragged looking line-wrap of paragraphs?
I'm not good enough in English spelling ;(
> 
> > Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
> > ---
> 
> In this space, please describe what happened during v1 and v2, and
> how is this round different to help reviewers. Pointers to list
> archive, e.g.
> http://thread.gmane.org/gmane.comp.version-control.git/181737, would
> be helpful.
> 
> People involved in v1/v2 discussion are missing from the Cc: line.
> Please do not give a false impression that you are hiding from them.
Oh, I've missed that moment, sorry all
> 
> > diff --git a/contrib/hooks/post-receive-email
> > b/contrib/hooks/post-receive-email index ba077c1..913be89 100755
> > --- a/contrib/hooks/post-receive-email
> > +++ b/contrib/hooks/post-receive-email
> > @@ -65,6 +65,14 @@
> >  #   Default is "--stat --summary --find-copies-harder". Add -p to
> > those #   options to include a unified diff of changes in addition
> > to the usual #   summary output.
> > +# hooks.gitopts
> > +#   git options for the git diff-tree invocation that shows
> > changes. +#   Default is '-c core.quotepath=false' to be able to
> > see non-ASCII filenames +#   used in a project.
> 
> We do not particularly appreciate a patch that does two unrelated
> things ("they are both related to post-receive-email" is not an
> argument). Wouldn't this be useful even if the change to add
> hooks.emailcharset turned out to be unwanted, or vice versa?
The main reason was that using core.quotepath=false leads to showing
file names "correctly" according to commit messages encoding to make
email-message look pretty.
> 
> > +# hooks.emailcharset
> > +#   The charset used in Content-Type header. UTF-8, if not
> > specified. +#   It can differ from i18n.logOutputEncoding (not to
> > mess-up with gitweb +#   which expects i18n.logOutputEncoding to be
> > set to UTF-8)
> 
> Why "UTF-8" instead of "i18n.logoutputencoding" if not specified?
Well, you're right.
For the explanation:
AFAIU, such hooks are used on central servers to notify involved people
about changes. And AFAIU the same server repos are used with gitweb
(which AFAIK requires i18n.logOutputEncoding=UTF-8)

But in common case "i18n.logoutputencoding" is more suitable.

> 
> > @@ -234,6 +242,9 @@ generate_email_header()
> >  	cat <<-EOF
> >  	To: $recipients
> >  	Subject: ${emailprefix}$projectdesc $refname_type
> > $short_refname ${change_type}d. $describe
> > +	MIME-Version: 1.0
> > +	Content-Type: text/plain; charset=$emailcharset
> > +	Content-Transfer-Encoding: 8bit
> >  	X-Git-Refname: $refname
> >  	X-Git-Reftype: $refname_type
> >  	X-Git-Oldrev: $oldrev
> > ...
> > @@ -730,6 +734,19 @@ custom_showrev=$(git config hooks.showrev)
> >  maxlines=$(git config hooks.emailmaxlines)
> >  diffopts=$(git config hooks.diffopts)
> >  : ${diffopts:="--stat --summary --find-copies-harder"}
> > +gitopts=$(git config hooks.gitopts || echo '-c
> > core.quotepath=false') +emailcharset=$(git config
> > hooks.emailcharset || echo 'UTF-8') +
> > +projectdesc=$(sed -ne '1p' "$GIT_DIR/description" 2>/dev/null)
> > +# Check if the description is unchanged from it's default, and
> > shorten it to +# a more manageable length if it is
> > +if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
> > +then
> > +	projectdesc="UNNAMED PROJECT"
> > +fi
> > +# Leave description in UTF-8 to be used in the Subject header
> > +# But convert it to an hooks.emailcharset encoding to be used in a
> > message body +projectdesc_e=$(echo $projectdesc | iconv -f UTF-8 -t
> > $emailcharset 2>/dev/null)
> 
> Hmm, this generates a piece of e-mail whose subject line is in UTF-8
> (without B/Q quoting) and message body is in totally different
> encoding. Is it what mailers really want to see?
Here you're right, too. Windows email clients may interpret Subject
header without B/Q quoting in its default Windows charset, and as far as
it may contain non-English project description, so Subject would look
ugly. But I'll try to test with some clients.
> 
> It almost seems backwards; converting the payload to UTF-8 and always
> sending UTF-8 would be a simpler approach, methinks.
Sounds reasonable