l10n: git.pot: v2.0.0 round 1 (45 new, 28 removed)

Generate po/git.pot from v2.0.0-rc0 for git v2.0.0 l10n round 1.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
l10n: vi.po (2228t): Update and minor fix

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
run_external_diff: use an argv_array for the command line

We currently generate the command-line for the external
command using a fixed-length array of size 10. But if there
is a rename, we actually need 11 elements (10 items, plus a
NULL), and end up writing a random NULL onto the stack.

Rather than bump the limit, let's just use an argv_array, which
makes this sort of error impossible.

Noticed-by: Max L <infthi.inbox@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
l10n: Update Swedish translation (2228t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
l10n: fr translation for v2.0.0rc0 (2228t)

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Matthieu Baerts <matttbe@gmail.com>
Signed-off-by: Xavier Mehrenberger <xavier.mehrenberger@gmail.com>
Merge branch 'fr-po' of git://github.com/jnavila/git

* 'fr-po' of git://github.com/jnavila/git:
  l10n: fr translation for v2.0.0rc0 (2228t)
l10n: zh_CN.po: translate 46 new messages (2229t0f0u)

Translations for git v2.0.0-rc0.  Also correct translatioins on relative
date in date.c with help from Brian Gesiak ($gmane/246390).

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR

The original implementation of CURL_CONFIG support did not match the
original behavior of using -lcurl when CURLDIR was not set. This broke
implementations that were lacking curl-config but did have libcurl
installed along system libraries, such as MSysGit. In other words, the
assumption that curl-config is always installed was incorrect.

Instead, if CURL_CONFIG is empty or returns an empty result (e.g. due
to curl-config being missing), use the old behavior of falling back to
-lcurl.

Signed-off-by: Dave Borowitz <dborowitz@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jk/external-diff-use-argv-array' (early part)

Crash fix for codepath that miscounted the necessary size for an
array when spawning an external diff program.

* 'jk/external-diff-use-argv-array' (early part):
  run_external_diff: use an argv_array for the command line
Merge branch 'db/make-with-curl'

It turns out that some platforms do ship without curl-config even
though they build with the hardcoded default -lcurl and rely on it
to work.

* db/make-with-curl:
  Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR
l10n: de.po: correct translation of "completed" after resolving deltas

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
l10n: de.po: translate 45 new messages

Translate 45 new messages came from git.pot update in 5e078fc
(l10n: git.pot: v2.0.0 round 1 (45 new, 28 removed)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Thomas Rast <tr@thomasrast.ch>
l10n: de.po: improve hint for autocorrected command execution

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Revert the whole "ask curl-config" topic for now

Postpone this a bit during the feature freeze and retry the effort
in the next cycle.
Merge git://github.com/git-l10n/git-po

* git://github.com/git-l10n/git-po:
  l10n: de.po: improve hint for autocorrected command execution
  l10n: de.po: translate 45 new messages
  l10n: de.po: correct translation of "completed" after resolving deltas
  l10n: zh_CN.po: translate 46 new messages (2229t0f0u)
  l10n: fr translation for v2.0.0rc0 (2228t)
  l10n: Update Swedish translation (2228t0f0u)
  l10n: vi.po (2228t): Update and minor fix
  l10n: git.pot: v2.0.0 round 1 (45 new, 28 removed)
within_depth: fix return for empty path

The within_depth function is used to check whether pathspecs
limited by a max-depth parameter are acceptable. It takes a
path to check, a maximum depth, and a "base" depth. It
counts the components in the path (by counting slashes),
adds them to the base, and compare them to the maximum.

However, if the base does not have any slashes at all, we
always return "true". If the base depth is 0, then this is
correct; no matter what the maximum is, we are always within
it. However, if the base depth is greater than 0, then we
might return an erroneous result.

This ends up not causing any user-visible bugs in the
current code. The call sites in dir.c always pass a base
depth of 0, so are unaffected. But tree_entry_interesting
uses this function differently: it will pass the prefix of
the current entry, along with a "1" if the entry is a
directory, in essence checking whether items inside the
entry would be of interest. It turns out not to make a
difference in behavior, but the reasoning is complex.

Given a tree like:

  file
  a/file
  a/b/file

walking the tree and calling tree_entry_interesting will
yield the following results:

  (with max_depth=0):
      file: yes
         a: yes
    a/file: no
       a/b: no

  (with max_depth=1):
      file: yes
         a: yes
    a/file: yes
       a/b: no

So we have inconsistent behavior in considering directories
interesting. If they are at the edge of our depth but at the
root, we will recurse into them, but then find all of their
entries uninteresting (e.g., in the first case, we will look
at "a" but find "a/*" uninteresting). But if they are at the
edge of our depth and not at the root, then we will not
recurse (in the second example, we do not even bother
entering "a/b").

This turns out not to matter because the only caller which
uses max-depth pathspecs is cmd_grep, which only cares about
blob entries. From its perspective, it is exactly the same
to not recurse into a subtree, or to recurse and find that
it contains no matching entries. Not recursing is merely an
optimization.

It is debatable whether tree_entry_interesting should
consider such an entry interesting. The only caller does not
care if it sees the tree itself, and can benefit from the
optimization. But if we add a "max-depth" limiter to regular
diffs, then a diff with DIFF_OPT_TREE_IN_RECURSIVE would
probably want to show the tree itself, but not what it
contains.

This patch just fixes within_depth, which means we consider
such entries uninteresting (and makes the current caller
happy).  If we want to change that in the future, then this
fix is still the correct first step, as the current behavior is
simply inconsistent.
teach tree-diff a max-depth parameter

When you are doing a tree-diff, there are basically two
options: do not recurse into subtrees at all, or recurse
indefinitely.  While most callers would want to always
recurse and see full pathnames, some may want the efficiency
of looking only at a particular level of the tree. This is
currently easy to do for the top-level (just turn off
recursion), but you cannot say "show me what changed in
subdir/, but do not recurse".

This patch adds a max-depth parameter which is measured from
the closest pathspec match, so that you can do:

  git log --raw --max-depth=1 a/b/c

and see the contents of a/b/c/, but not those of a/b/c/d/
(you would see the --raw entry for a/b/c/d in such a case).
combine-diff: zero memory used for callback filepairs

In commit 25e5e2b, the combined-diff code learned how to
make a multi-sourced diff_filepair to pass to a diff
callback. When we create each filepair, we do not bother to
fill in many of the fields, because they would make no sense
(e.g., there can be no rename score or broken_pair flag
because we do not go through the diffcore filters). However,
we did not even bother to zero them, leading to random
values. Let's make sure everything is blank with xcalloc,
just as the regular diff code does.

We would potentially want to set the "status" flag to
something non-zero, but it is not clear to what. Possibly a
new DIFF_STATUS_COMBINED would make sense, as this is not
strictly a modification, nor does it fit any other category.

Since it is not yet clear what callers would want, this
patch simply leaves it as "0", the same empty flag that is
seen when diffcore_std is not used at all.
add blame-tree command

This command shows the most recent modification to paths in
a tree. It does so by expanding the tree at a given commit,
taking note of the current state of each path, and then
walking backwards through history looking for commits where
each path changed into its final sha1.