l10n: git.pot: v2.2.0 round 2 (1 updated)

Generate po/git.pot from v2.2.0-rc2-23-gca0107e for git v2.2.0 l10n
round 2.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
l10n: batch updates for one trivial change

In order to catch up with the release of Git 2.2.0 final, make a batch
l10n update for the new l10n change brought by commit d52adf1 (trailer:
display a trailer without its trailing newline).

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

Signed-off-by: Phillip Sz <phillip.szelat@gmail.com>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
l10n: de.po: translate 2 messages

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
l10n: remove a superfluous translation for push.c

Ralf reported that '--recurse-submodules' option in push.c should not be
translated [1].  Before his commit is merged, remove superfluous
translations for push.c.

[1] http://www.spinics.net/lists/git/msg241964.html

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

Signed-off-by: Junio C Hamano <gitster@pobox.com>
index-pack: handle duplicate base objects gracefully

If a pack contains duplicates of an object, and if that
object has any deltas pointing at it with REF_DELTA, we will
try to resolve the deltas twice. While unusual, this is not
strictly an error, but we currently die() with an unhelpful
message.  We should instead silently ignore the delta and
move on. The first resolution already filled in any data we
needed (like the sha1).

The duplicate base object is not our concern during the
resolution phase, and the .idx-writing phase will decide
whether to complain or allow it (based on whether --strict
is set).

Based-on-work-by: René Scharfe <l.s.r@web.de>
t5309: mark delta-cycle failover tests as passing

t5309 checks that we detect and fail when there is a cycle
of deltas (i.e., A is a delta on B, which is a delta on A).
It also checks the cases where we have such a cycle, but we
have an extra copy of the object either in the same pack or
in another one. These cases are recoverable, because we can
use the alternate copy to reconstruct the delta object.

However, it did not work in practice (and the tests were
marked as expect_failure) because it led to us trying to
resolve some deltas multiple times, something we assert()
should not happen. E.g., we'd see the full base A, use it to
resolve delta B on top of A, then use that to resolve the
delta A on top of B, and then finally try resolving B on top
of A again.

Since the previous commit, we handle duplicate bases more
gracefully, and the tests pass. While we're here, let's also
make the tests a little more robust:

  1. For the case of finding the extra base in the same
     pack, we do not need to use --fix-thin; it should (and
     does) work without it.

  2. Confirm that the resulting pack has a duplicate object.
     In the case of using --fix-thin to pull the object from
     another pack, the duplicate is added to the pack by us
     (this is a good thing, as otherwise future readers
     would encounter the cycle again).
demonstrate horrible breakage