remote-hg: don't decode UTF-8 paths into Unicode objects

The internal mercurial API expects ordinary 8-bit string objects, not
Unicode string objects.  With this change, the test-hg.sh unit tests
pass again.

Signed-off-by: Richard Hansen <rhansen@bbn.com>
Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
RelNotes: spelling & grammar fixes

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'mb/relnotes-1.8.5-fix'

* mb/relnotes-1.8.5-fix:
  RelNotes: spelling & grammar fixes
Git 1.8.4.4

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with 1.8.4.4
Git 1.8.5-rc3

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'rh/remote-hg-bzr-updates' (early part)

Unbreaks a recent breakage due to use of unquote-c-style.

This may need to be cherry-picked down to 1.8.4.x series.

* 'rh/remote-hg-bzr-updates' (early part):
  remote-hg: don't decode UTF-8 paths into Unicode objects
remote-hg: don't decode UTF-8 paths into Unicode objects

The internal mercurial API expects ordinary 8-bit string objects, not
Unicode string objects.  With this change, the test-hg.sh unit tests
pass again.

Signed-off-by: Richard Hansen <rhansen@bbn.com>
Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with maint

* maint:
  remote-hg: don't decode UTF-8 paths into Unicode objects
Git 1.8.5

Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule: do not copy unknown update mode from .gitmodules

When submodule.$name.update is given as hint from the upstream in
the .gitmodules file, we used to blindly copy it to .git/config,
unless there already is a value defined for the submodule.

However, there is no reason to expect that the update mode hinted by
the upstream is available in the version of Git the user is using,
and a really custom "!cmd" prepared by an upstream person running on
Linux may not even be available to a user on Windows.  It is simply
irresponsible to copy the setting blindly and to attempt to use it
during a later "submodule update" without validating it first.

Just show the suggested value to the diagnostic output, and set the
value to 'none' in the configuration, if it is not one of the ones
that are known to be supported by this version of Git.

Helped-by: Jens Lehmann <Jens.Lehmann@web.de>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git 1.8.4.5

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with 1.8.4.5
commit -v: strip diffs and submodule shortlogs from the commit message

When using the '-v' option of "git commit" the diff added to the commit
message temporarily for editing is stripped off after the user exited the
editor by searching for "\ndiff --git " and truncating the commmit message
there if it is found.

But this approach has two problems:

- when the commit message itself contains a line starting with
  "diff --git" it will be truncated there prematurely; and

- when the "diff.submodule" setting is set to "log", the diff may
  start with "Submodule <hash1>..<hash2>", which will be left in
  the commit message while it shouldn't.

Fix that by introducing a special scissor separator line starting with the
comment character ('#' or the core.commentChar config if set) followed by
two lines describing what it is for. The scissor line - which will not be
translated - is used to reliably detect the start of the diff so it can be
chopped off from the commit message, no matter what the user enters there.

Turn a known test failure fixed by this change into a successful test;
also add one for a diff starting with a submodule log and another one for
proper handling of the comment char.

Reported-by: Ari Pollak <ari@debian.org>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>