po/TEAMS: add new member to German translation team

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
l10n: de.po: change Email to E-Mail

Change all Email to E-Mail, as this is the correct form in German.

Signed-off-by: Phillip Sz <phillip.szelat@gmail.com>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
l10n: de.po: use comma before "um"

This patch adds a comma before the "um". See:
http://www.duden.de/sprachwissen/rechtschreibregeln/komma#K117

Signed-off-by: Phillip Sz <phillip.szelat@gmail.com>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Merge branch 'maint' of git://github.com/git-l10n/git-po into maint

* 'maint' of git://github.com/git-l10n/git-po:
  l10n: de.po: use comma before "um"
  l10n: de.po: change Email to E-Mail
  po/TEAMS: add new member to German translation team
Merge branch 'maint'

* maint:
  l10n: de.po: use comma before "um"
  l10n: de.po: change Email to E-Mail
  po/TEAMS: add new member to German translation team
Sync with master

* master:
  l10n: de.po: use comma before "um"
  l10n: de.po: change Email to E-Mail
  po/TEAMS: add new member to German translation team
t/perf-lib: factor boilerplate out of test_perf

About half of test_perf() is boilerplate, and half is
actually related to running the perf test. Let's split it
into two functions, so that we can reuse the boilerplate in
future commits.
t/perf/aggregate: factor our percent calculations

This will let us reuse the code when we add new values to
aggregate besides times.
t/perf: add infrastructure for measuring sizes

The main objective of scripts in the perf framework is to
run "test_perf", which measures the time it takes to run
some operation. However, it can also be interesting to see
the change in the output size of certain operations.

This patch introduces test_size, which records a single
numeric output from the test and shows it in the aggregated
output (with pretty printing and relative size comparison).
upload-archive: restrict remote objects with reachability check

When serving a remote request, git-upload-archive tries to
restrict access to unreachable objects, which matches the
behavior of upload-pack. However, we did so by restricting
the requested tree to "<ref>[:<path>]", because it is fast.
That covers the common cases, but does not allow requesting
items by a specific sha1 (either a tree or a commit sha1).

Instead, let's do the correct-but-slower method of actually
walking back from the tips to see if the requested object is
reachable. The performance impact of this is roughly:

  1. For a recent commit, the speed is about the same (we
     traverse in reverse chronological order, so we see it
     almost immediately).

  2. For an older commit, even one pointed at directly by a
     ref (e.g., an old tag), we are slower, because we
     traverse from the more recent tips. We are bounded in
     this case by the time to look at all commits (i.e.,
     "time git rev-list --all").

  3. When we see "$ref:$path", we typically perform much
     worse, because our traversal looks at all commits
     first, followed by all trees.

  4. The worst case (which we hit for an unreachable object)
     is equivalent to "time rev-list --objects --all", which
     is about the same amount of time pack-objects spends
     preparing a full clone (which can be in the tens of
     seconds for a large repository).

The implementation is a fairly straightforward application
of the traverse_commit_list function. Using the
mark_objects_reachable function would seem more appropriate,
but it has no mechanism for looking for a specific object,
which lets us end the traversal early in common cases.
t/perf: add perf tests for fetches from a bitmapped server

A server with bitmapped packs can serve a clone very
quickly. However, fetches are not necessarily made any
faster, because we spend a lot less time in object traversal
(which is what bitmaps help with) and more time finding
deltas (because we may have to throw out on-disk deltas if
the client does not have the other side).

As a first step to making this faster, this patch introduces
a new perf script to measure fetches into a repo of various
ages from a fully-bitmapped server.

We separately measure the work done by the server (in
pack-objects) and that done by the client (in index-pack).
Furthermore, we measure the size of the resulting pack.

Breaking it down like this (instead of just doing a regular
"git fetch") lets us see how much each side benefits from
any changes. And since we know the pack size, if we estimate
the network speed, then we can calculate a complete
wall-clock time for the operation.
list-objects: optimize "revs->blob_objects = 0" case

If we are traversing trees during a "--objects"
traversal, we may skip blobs if the "blob_objects" field of
rev_info is not set. But we do so as the first thing in
process_blob(), only after we have actually created the
"struct blob" object, incurring a hash lookup. We can
optimize out this no-op call completely.

This does not actually affect any current code, as all of
the current traversals always set blob_objects when looking
at objects, anyway.
pack-bitmap: save "have" bitmap from walk

When we do a bitmap walk, we save the result, which
represents (WANTs & ~HAVEs); i.e., every object we care
about visiting in our walk. However, we throw away the
haves bitmap, which can sometimes be useful, too. Save it
and provide an access function so code which has performed a
walk can query it.
archive: ignore blob objects when checking reachability

We cannot create an archive from a blob object, so we would
not expect anyone to provide one to us. And if they do, we
will fail anyway just after the reachability check.  We can
therefore optimize our reachability check to ignore blobs
completely, and not even create a "struct blob" for them.

Depending on the repository size and the exact place we find
the reachable object in the traversal, this can save 20-25%,
a we can avoid many lookups in the object hash.

The downside of this is that a blob provided to a remote
archive process will fail with "no such object" rather than
"object is not a tree" (we could organize the code to retain
the old message, but since we no longer know whether the
blob is reachable or not, we would potentially be leaking
information about the existence of unreachable objects).
pack-objects: reuse deltas for thin "have" objects

When we calculate the "wants" and "haves" for a pack, we
only add the objects in the boundary commits as preferred
bases. However, we know that every object reachable from the
"haves" could be a preferred base.

We probably don't want to add these to our preferred base
list, because they would clog the delta-search window.
However, there is no reason we cannot reuse an on-disk delta
against such a deep "have" base, avoiding the delta search
for that object altogether.
t5000: drop tag to supposedly unreachable object

We try to create an unreachable commit, but test_commit will
retain a tag pointing to it. Oops.
preferred base reuse wip
wip -- better protection against corruption
check_everything_connected: use argv_array

This saves us from manually counting our array, and makes
further refactoring simpler.
check_everything_connected: assume alternate ref tips are valid

When we receive a remote ref update to sha1 "X", we want to
check that we have all of the objects needed by "X". We can
assume that our repository is not currently corrupted, and
therefore if we have a ref pointing at "Y", we have all of
its objects.  We can therefore stop our traversal from "X"
as soon as we hit "Y".

If we make the same non-corruption assumption about any
repositories we use to store alternates, then we can also
use their ref tips to shorten the traversal.

This is especially useful when cloning with "--reference",
as we otherwise do not have any local refs to check against,
and have to traverse the whole history, even though the
other side may have sent us few or no objects.