t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs

The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
pretty: Add failing tests: --format output should honor logOutputEncoding

One can set an alias
	$ git config alias.lg "log --graph --pretty=format:'%Cred%h%Creset
	-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
	--abbrev-commit --date=local"

to see the log as a pretty tree (like *gitk* but in a terminal).

However, log messages written in an encoding i18n.commitEncoding which differs
from terminal encoding are shown corrupted even when i18n.logOutputEncoding
and terminal encoding are the same (e.g. log messages committed on a Cygwin box
with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice versa).

To simplify an example we can say the following two commands are expected
to give the same output to a terminal:

	$ git log --oneline --no-color
	$ git log --pretty=format:'%h %s'

However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it formats "%s".

The same corruption is true for
	$ git diff --submodule=log
and
	$ git rev-list --pretty=format:%s HEAD
and
	$ git reset --hard

This patch adds failing tests for the next patch that fixes them.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
pretty: --format output should honor logOutputEncoding

One can set an alias
	$ git config [--global] alias.lg "log --graph --pretty=format:'%Cred%h%Creset
	-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
	--abbrev-commit --date=local"

to see the log as a pretty tree (like *gitk* but in a terminal).

However, log messages written in an encoding i18n.commitEncoding which differs
from terminal encoding are shown corrupted even when i18n.logOutputEncoding
and terminal encoding are the same (e.g. log messages committed on a Cygwin box
with Windows-1251 encoding seen on a Linux box with a UTF-8 encoding and vice versa).

To simplify an example we can say the following two commands are expected
to give the same output to a terminal:

	$ git log --oneline --no-color
	$ git log --pretty=format:'%h %s'

However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it formats "%s".

The same corruption is true for
	$ git diff --submodule=log
and
	$ git rev-list --pretty=format:%s HEAD
and
	$ git reset --hard

This patch makes pretty --format honor logOutputEncoding when it formats
log message.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
post-receive-email: explicitly set Content-Type header

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>
gitweb: Configurable hyperlinking

Commit messages of many projects refer to issues of bugtracking
systems, e.g.'Fixed: #NNN...'. This adds an ability to convert such strings
to hyperlinks leading to a corresponding issues in bugtracking system.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Configurable hyperlinking in gitk

Many projects use project-specific notations in changelogs to refer
to bug trackers and the like.  One example is the "Closes: #12345"
notation used in Debian.

Make gitk configurable so that arbitrary strings can be turned into
clickable links that are opened in a web browser.

Signed-off-by: Jeff Epler <jepler@unpythonic.net>
t9901-git-web--browse.sh: Use "write_script" helper

Use "write_script" helper as suggested by Junio C Hamano.
Also, replace `pwd` with $(pwd) call convention.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
git-web--browser: avoid errors in terminal when running Firefox on Windows

Firefox on Windows by default is placed in "C:\Program Files\Mozilla Firefox"
folder, i.e. its path contains spaces. Before running this browser "git-web--browse"
tests version of Firefox to decide whether to use "-new-tab" option or not.

Quote browser path to avoid error during this test.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
format-patch: cover letter does not respect i18n.commitencoding

When we write a cover letter it is naturally enough to suppose
that we use the same encoding as we do commits in. So make
"format-patch --cover-letter" to use i18n.commitencoding setting
in "Content-Type" header of a cover letter instead of hard-coded "UTF-8".
Especially as cover letter contains shortlog and diffstat of patches
which can contain author names and file names in i18n.commitencoding.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
send-email: Honor multi-part email messages

"git format-patch --attach/--inline" generates multi-part messages.
Every part of such messages can contain non-ASCII characters with its own
"Content-Type" and "Content-Transfer-Encoding" headers.
But git-send-mail script interprets a patch-file as one-part message
and does not recognize multi-part messages.
So already quoted printable email subject may be encoded as quoted printable
again. Due to this bug email subject looks corrupted in email clients.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
improved: + Makefile to simplify build and redistribution on Cygwin