git-multimail: update to version 1.0.0

This commit contains the squashed changes from the upstream
git-multimail repository since the last code drop.  Highlights:

* Fix encoding of non-ASCII email addresses in email headers.

* Fix backwards-compatibility bugs for older Python 2.x versions.

* Fix a backwards-compatibility bug for Git 1.7.1.

* Add an option commitDiffOpts to customize logs for revisions.

* Pass "-oi" to sendmail by default to prevent premature
  termination
  on a line containing only ".".

* Stagger email "Date:" values in an attempt to help mail clients
  thread the emails in the right order.

* If a mailing list setting is missing, just skip sending the
  corresponding email (with a warning) instead of failing.

* Add a X-Git-Host header that can be used for email filtering.

* Allow the sender's fully-qualified domain name to be configured.

* Minor documentation improvements.

* Add a CHANGES file.

Contributions-by: Raphaël Hertzog <hertzog@debian.org>
Contributions-by: Eric Berberich <eric.berberich@gmail.com>
Contributions-by: Michiel Holtkamp <git@elfstone.nl>
Contributions-by: Malte Swart <mswart@devtation.de>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
utf8.c: partially update to version 6.3

Unicode 6.3 defines more code points as combining or accents.  For
example, the character "ö" could be expressed as an "o" followed by
U+0308 COMBINING DIARESIS (aka umlaut, double-dot-above).  We should
consider that such a sequence of two codepoints occupies one display
column for the alignment purposes, and for that, git_wcwidth()
should return 0 for them.  Affected codepoints are:

    U+0358..U+035C
    U+0487
    U+05A2, U+05BA, U+05C5, U+05C7
    U+0604, U+0616..U+061A, U+0659..U+065F

Earlier unicode standards had defined these as "reserved".

Only the range 0..U+07FF has been checked to see which codepoints
need to be marked as 0-width while preparing for this commit; more
updates may be needed.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test: fix t7001 cp to use POSIX options

Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the
t7001-mv test has used "cp -a" to perform a copy in several of the
tests.

However, the "-a" option is not required for a POSIX cp utility and
some platforms' cp utilities do not support it.

The POSIX equivalent of -a is -R -P -p.

Change "cp -a" to "cp -R -P -p" so that the t7001-mv test works
on systems with a cp utility that only implements the POSIX
required set of options and not the "-a" option.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test: fix t5560 on FreeBSD

Since fd0a8c2e (first appearing in v1.7.0), the
t/t5560-http-backend-noserver.sh test has used a backslash escape
inside a ${} expansion in order to specify a literal '?' character.

Unfortunately the FreeBSD /bin/sh does not interpret this correctly.

In a POSIX compliant shell, the following:

x='one?two?three'
echo "${x#*\?}"

Would be expected to produce this:

two?three

When using the FreeBSD /bin/sh instead you get this:

one?two?three

In fact the FreeBSD /bin/sh treats the backslash as a literal
character to match so that this:

y='one\two\three'
echo "${y#*\?}"

Produces this unexpected value:

wo\three

In this case the backslash is not only treated literally, it also
fails to defeat the special meaning of the '?' character.

Instead, we can use the [...] construct to defeat the special meaning
of the '?' character and match it exactly in a way that works for the
FreeBSD /bin/sh as well as other POSIX /bin/sh implementations.

Changing the example like so:

x='one?two?three'
echo "${x#*[?]}"

Produces the expected output using the FreeBSD /bin/sh.

Therefore, change the use of \? to [?] in order to be compatible with
the FreeBSD /bin/sh which allows t/t5560-http-backend-noserver.sh to
pass on FreeBSD again.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'km/avoid-bs-in-shell-glob'

Portability fix.

* km/avoid-bs-in-shell-glob:
  test: fix t5560 on FreeBSD
Merge branch 'km/avoid-cp-a'

Portability fix.

* km/avoid-cp-a:
  test: fix t7001 cp to use POSIX options
Merge branch 'tb/unicode-6.3-zero-width'

Teach our display-column-counting logic about decomposed umlauts
and friends.

* tb/unicode-6.3-zero-width:
  utf8.c: partially update to version 6.3
Merge branch 'mh/multimail'

* mh/multimail:
  git-multimail: update to version 1.0.0
Update draft release notes for 2.0

Signed-off-by: Junio C Hamano <gitster@pobox.com>
i18n: Fixes uncatchable comments for translators

Comment for l10n translators can not be extracted by xgettext if it is
not right above the l10n tag.  Moving the comment right before the l10n
tag will fix this issue.

Reported-by: Brian Gesiak <modocache@gmail.com>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
i18n: Only extract comments marked by special tag

When extract l10n messages, we use "--add-comments" option to keep
comments right above the l10n messages for references.  But sometimes
irrelevant comments are also extracted.  For example in the following
code block, the comment in line 2 will be extracted as comment for the
l10n message in line 3, but obviously it's wrong.

        { OPTION_CALLBACK, 0, "ignore-removal", &addremove_explicit,
          NULL /* takes no arguments */,
          N_("ignore paths removed in the working tree (same as
          --no-all)"),
          PARSE_OPT_NOARG, ignore_removal_cb },

Since almost all comments for l10n translators are marked with the same
prefix (tag): "TRANSLATORS:", it's safe to only extract comments with
this special tag.  I.E. it's better to call xgettext as:

        xgettext --add-comments=TRANSLATORS: ...

Also tweaks the multi-line comment in "init-db.c", to make it start with
the proper tag, not "* TRANSLATORS:" (which has a star before the tag).

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
i18n: Remove obsolete comments for translators

Since we do not translate diffstat any more, remove the obsolete comments.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
l10n: git.pot: proposed updates for v2.0.0 (+45)

The 1st round of Git l10n often starts very late duing the release
cycle of Git, usually after the release of rc1. This leads to a
gaint update of "po/git.pot" and lots of works for translators with
a tight deadline (about one week).

This "pu" branch holds proposed updates of the file "po/git.pot" for
Git next release (2.0.0), and will be updated and rewound without
notification when there are remarkable updates for it.

Translators could work on this "pu" branch before the l10n coordinator
starts the 1st round of l10n for this release cycle of Git, and
rebase their works onto the master branch (with the commit for the
1st round of l10n), then send pull request to the l10n coordinator.

Please note:

 1. Because this branch will be rewound occasionally, translators
    SHOULD NOT merge, but SHOULD rebase to this rewound branch
    instead.

        $ git fetch git://github.com/git-l10n/git-po.git pu
        $ git rebase --onto FETCH_HEAD HEAD~1

 2. Update your translated message file "po/XX.po".

        $ msgmerge --add-location --backup=off -U "po/XX.po" \
          po/git.pot

 3. Then start to translate "po/XX.po" and commit.

 4. DO NOT send pull request to the l10n coordinator for
    translations on this "pu" branch.

 5. When the l10n coordinator starts the 1st round l10n for the
    current Git release cycle, translators should rebase and squash
    their works onto the master branch, and then send pull request.

        $ git fetch git://github.com/git-l10n/git-po.git master
        $ git rebase --onto FETCH_HEAD HEAD~1

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>