fmt-merge-msg: make attribution into comment lines

The submaintainer credit is not something you can compute purely by
looking at the history and its shape, especially in the presense of
fast-forward merges, and this observation makes the information on
the "via" line unreliable.  Let's leave the final determination of
credits up to whoever is making the merge and show them as comments.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
l10n: Update git.pot (27 new, 1 removed messages)

Extract messages marked by shell gettext wrappers which are ignored
before. See:

 * http://thread.gmane.org/gmane.comp.version-control.git/199112

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
l10n: zh_CN.po: translate 27 new messages

Translate 19 new and 8 fuzzy messages which are marked by shell gettext
wrappers, and ignored by previous 'git.pot' updates.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
docs: fix cross-directory linkgit references

Most of our documentation is in a single directory, so using
linkgit:git-config[1] just generates a relative link in the
same directory. However, this is not the case with the API
documentation in technical/*, which need to refer to
git-config from the parent directory.

We can fix this by passing a special prefix attribute when building
in a subdirectory, and respecting that prefix in our linkgit
definitions.

We only have to modify the html linkgit definition.  For
manpages, we can ignore this for two reasons:

  1. we do not generate actual links to the file in
     manpages, but instead just give the name and section of
     the linked manpage

  2. we do not currently build manpages for subdirectories,
     only html

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'mm/api-credentials-doc'

Finishing touches...

* mm/api-credentials-doc:
  docs: fix cross-directory linkgit references
l10n: Update  po/vi.po to v1.7.11.rc2.2.gb694fbb

 * Translated 28 strings.

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
git-svn: make Git::SVN::Editor a separate file

This makes the git-svn script shorter and less scary for beginners to
read through for the first time.  Take the opportunity to explain the
purpose and basic interface of the Git::SVN::Editor class while at it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn: make Git::SVN::RA a separate file

This slices off another 600 or so lines from the frighteningly long
git-svn.perl script.

The Git::SVN::Ra interface is similar enough to SVN::Ra that it is
probably safe to ignore most of its implementation on first reading.
(Documenting or moving functions that do not fit that pattern is left
as an exercise to the interested reader.)

[ew: rebased and fixed conflict against
 commit c26ddce86d7215b4d9687bd4c6b5dd43a3fabf31
 (git-svn: platform auth providers are working only on 1.6.15 or newer)]

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn: use YAML format for mergeinfo cache when possible

Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
git-svn has maintained some private per-repository caches in
.git/svn/.caches to avoid refetching and recalculating some
mergeinfo-related information with every "git svn fetch".

These caches use the 'nstore' format from the perl core module
Storable, which can be read and written quickly and was designed for
transfer over the wire (the 'n' stands for 'network').  This format is
endianness-independent and independent of floating-point
representation.

Unfortunately the format is *not* independent of the perl version ---
new perl versions will write files that very old perl cannot read.
Worse, the format is not independent of the size of a perl integer.
So if you toggle perl's use64bitint compile-time option, then using
'git svn fetch' on your old repositories produces errors like this:

	Byte order is not compatible at ../../lib/Storable.pm (autosplit
	into ../../lib/auto/Storable/_retrieve.al) line 380, at
	/usr/share/perl/5.12/Memoize/Storable.pm line 21

That is, upgrading perl to a version that uses use64bitint for the
first time makes git-svn suddenly refuse to fetch in existing
repositories.  Removing .git/svn/.caches lets git-svn recover.

It's time to switch to a platform independent serializer backend with
better compatibility guarantees.  This patch uses YAML::Any.

Other choices were considered:

 - thawing data from Data::Dumper involves "eval".  Doing that without
   creating a security risk is fussy.

 - the JSON API works on scalars in memory and doesn't provide a
   standard way to serialize straight to disk.

YAML::Any is reasonably fast and has a pleasant API.  In most
backends, LoadFile() reads the entire file into a scalar anyway and
converts it as a second step, but having an interface that allows the
deserialization to happen on the fly without a temporary is still a
comfort.

YAML::Any is not a core perl module, so we take care to use it when
and only when it is available.  Installations without that module
should fall back to using Storable with all its quirks, keeping their
cache files in

	.git/svn/.caches/*.db

Installations with YAML peacefully coexist by keeping a separate set
of cache files in

	.git/svn/.caches/*.yaml.

In most cases, switching between is a one-time thing, so it doesn't
seem worth the complication to migrate existing caches.

The upshot: after this patch, as long as YAML::Any is installed you
can move your git repository between machines with different perl
installations and "git svn fetch" will work fine.  If you do not have
YAML::Any, the behavior is unchanged (and in particular does not get
any worse).

Reported-by: Sandro Weiser <sandro.weiser@informatik.tu-chemnitz.de>
Reported-by: Bdale Garbee <bdale@gag.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
l10n: de.po: translate 27 new messages

Translate 27 new messages came from git.pot update
in 7256fd7 (l10n: Update git.pot (27 new, 1 removed messages)).

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
fast-export: report SHA-1 instead of gibberish when marks exist already

Cc: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Max Horn <max@quendi.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'js/maint-fast-export-mark-error'

* js/maint-fast-export-mark-error:
  fast-export: report SHA-1 instead of gibberish when marks exist already
api-credential.txt: document that helpers field is filled-in automatically

It was unclear whether the field was to be specified by the user of the
API.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jc/fmt-merge-msg-people'

Tone down the lines that credit people involved and make them
comments, so that integrators who edit their merge messages can
still make use of the information, but lazy ones will not leave
the unverified guesses placed on the "via" line.

* jc/fmt-merge-msg-people:
  fmt-merge-msg: make attribution into comment lines
Merge branch 'mm/api-credentials-doc'

* mm/api-credentials-doc:
  api-credential.txt: document that helpers field is filled-in automatically
Merge git://github.com/ralfth/git-po-de

By Ralf Thielow
via Ralf Thielow
* github.com/ralfth/git-po-de:
  l10n: de.po: translate 27 new messages
Merge git://github.com/git-l10n/git-po

Updates to German, Vietnamese and simplified Chinese translation.

* git://github.com/git-l10n/git-po:
  l10n: de.po: translate 27 new messages
  l10n: Update  po/vi.po to v1.7.11.rc2.2.gb694fbb
  l10n: zh_CN.po: translate 27 new messages
  l10n: Update git.pot (27 new, 1 removed messages)
Git 1.7.11-rc3

Signed-off-by: Junio C Hamano <gitster@pobox.com>
t9350: point out that refs are not updated correctly

This happens only when the corresponding commits are not exported in
the current fast-export run. This can happen either when the relevant
commit is already marked, or when the commit is explicitly marked
as UNINTERESTING with a negative ref by another argument.

This breaks fast-export basec remote helpers.

Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
fast-export: do not refer to non-existing marks

When calling `git fast-export a..a b` when a and b refer to the same
commit, nothing would be exported, and an incorrect reset line would
be printed for b ('from :0').

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>