patchtg-create.sh: Support for multiple {to,cc,bcc} options

> Git config supports multiple values for the same config key, so support it
> for these TopGit config options, too.
> 
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
> 
> ---
>  tg-create.sh |   17 ++++++++++++++---
>  1 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/tg-create.sh b/tg-create.sh
> index 6cce7ed..d47959b 100644
> --- a/tg-create.sh
> +++ b/tg-create.sh
> @@ -100,13 +100,24 @@ git checkout -b "$name"
>  echo "$deps" | sed 's/ /\n/g' >"$root_dir/.topdeps"
>  git add "$root_dir/.topdeps"
>  
> +# Print each config value for a key ($1, without "topgit." prefix)
> +# with the given prefix ($2)
> +get_multi_config()
> +{
> +	# escape any / in prefix for sed
> +	prefix="$(echo "$2" | sed -e 's/\//\\\\\//g')"

>  author="$(git var GIT_AUTHOR_IDENT)"
>  author_addr="${author%> *}>"
>  {
>  	echo "From: $author_addr"
> -	! header="$(git config topgit.to)" || echo "To: $header"
> -	! header="$(git config topgit.cc)" || echo "Cc: $header"
> -	! header="$(git config topgit.bcc)" || echo "Bcc: $header"
> +	get_multi_config to  "To:"
> +	get_multi_config cc  "Cc:"
> +	get_multi_config bcc "Bcc:"
>  	! subject_prefix="$(git config topgit.subjectprefix)" || subject_prefix="$subject_prefix "
>  	echo "Subject: [${subject_prefix}PATCH] $name"
>  	echo

>> +
>> +	git config --get-all topgit.$1 2>/dev/null |
>> +		sed -e "s/^/$prefix /g"
>> +}
>
> Won't this return an error code and terminate the script in case no
> option is defined?

>> -	! header="$(git config topgit.to)" || echo "To: $header"
>> -	! header="$(git config topgit.cc)" || echo "Cc: $header"
>> -	! header="$(git config topgit.bcc)" || echo "Bcc: $header"
>> +	get_multi_config to  "To:"
>> +	get_multi_config cc  "Cc:"
>> +	get_multi_config bcc "Bcc:"
>>  	! subject_prefix="$(git config topgit.subjectprefix)" || subject_prefix="$subject_prefix "
>>  	echo "Subject: [${subject_prefix}PATCH] $name"
>>  	echo
>
> One trouble here is that I've seen mailers mess up when there is
> multiple occurences of these headers, so it would be probably safer to
> concatenate them all to single line, comma-separated.

> Petr Baudis <pasky@suse.cz> writes:
>
>>> +    prefix="$(echo "$2" | sed -e 's/\//\\\\\//g')"
>>
>> Maybe use s### ? ;-)
>
> Personally I like '|' instead.  It's much less visually distracting than #.

>
>>> +
>>> +    git config --get-all topgit.$1 2>/dev/null |
>>> +            sed -e "s/^/$prefix /g"
>>> +}
>>
>> Won't this return an error code and terminate the script in case no
>> option is defined?

>>> -    ! header="$(git config topgit.to)" || echo "To: $header"
>>> -    ! header="$(git config topgit.cc)" || echo "Cc: $header"
>>> -    ! header="$(git config topgit.bcc)" || echo "Bcc: $header"
>>> +    get_multi_config to  "To:"
>>> +    get_multi_config cc  "Cc:"
>>> +    get_multi_config bcc "Bcc:"
>>>      ! subject_prefix="$(git config topgit.subjectprefix)" || subject_prefix="$subject_prefix "
>>>      echo "Subject: [${subject_prefix}PATCH] $name"
>>>      echo
>>
>> One trouble here is that I've seen mailers mess up when there is
>> multiple occurences of these headers, so it would be probably safer to
>> concatenate them all to single line, comma-separated.
>
> It is not just "I've seen mailers"; RFC2822 wants you to have at most one
> (see the table on Page 20).

> Petr Baudis <pasky@suse.cz> writes:
> 
> >> +	prefix="$(echo "$2" | sed -e 's/\//\\\\\//g')"
> >
> > Maybe use s### ? ;-)
> 
> Personally I like '|' instead.  It's much less visually distracting than #.

> >> +
> >> +	git config --get-all topgit.$1 2>/dev/null |
> >> +		sed -e "s/^/$prefix /g"
> >> +}
> >
> > Won't this return an error code and terminate the script in case no
> > option is defined?
> 
> Exit code from upstream of a pipe does not affect the exit code from the
> pipeline, and sed does not exit non-zero just because there was no
> substitution.

>> >> +
>> >> +  git config --get-all topgit.$1 2>/dev/null |
>> >> +          sed -e "s/^/$prefix /g"
>> >> +}
> I still don't understand the stderr redirect, though.