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)
delete_ref: avoid stale-lock race while deleting loose ref

When we take a lock on a ref, we do not remember the actual
filename of the ref, but rather only its lockfile, which
will be `$GIT_DIR/$ref.lock`. To delete the loose ref
itself, we munge the lockfile's buffer to drop the ".lock"
suffix, delete the loose ref file, then restore the original
buffer.

If we happen to receive a signal while the filename is
munged, then our automatic cleanup for the lockfile will
kick in, but it will delete the wrong file (i.e., the actual
loose ref file). This isn't that bad, as the point of the
code is to delete that file anyway, so nothing of value is
lost.  However, we will fail to delete our real lockfile,
leaving a stale lock in place.
add API for cleaning up temporary files on exit

Many parts of the code introduce temporary files, and then
clean them up with a custom signal/atexit handler. We can
reduce code duplication and make it simpler to add tempfile
handling in new places by abstracting this into a simple
API.

The API is based largely on the lockfile cleanup code, which
is the most comprehensive. In particular, it has a few
features that other tempfile code does not:

  1. It keeps an "owner" field with the pid of the process
     that took the lock. That means that a sub-process
     (e.g., start_async on a machine without pthreads) will
     not accidentally clean up the tempfiles.

  2. It keeps the file descriptor of the opened tempfile.
     Ideally the tempfile code would not need to care about
     the descriptor at all, and only unlink the filename;
     however, on some systems one must close the file before
     unlinking (e.g., Windows).

In addition, we add one new feature not present even in the
lockfile code: an "active" flag. The lockfile code decides
that a non-empty filename field in the lock means that the
entry is valid.  Because we may reuse a "struct lock_file",
meaning it is already on the list of items to be cleaned,
and because we write the lockfile name into the "struct
lock_file" before we open it, there is a race that can
happen like:

  1. We write "foo.lock" into a "struct lock_file" that has
     previously been used.

  2. We try to acquire the lock but fail because it is
     already locked.

  3. Before we get a chance to zero out lk->filename[0], we
     get a signal.

  4. The signal runs remove_lock_file_on_signal, which
     thinks that the lockfile is valid and removes it.

The new tmpfile code solves this by keeping an active flag,
and never turning it on until we are sure the file is
"ours" (and turning it off before dropping control of
the file via rename or removal).
lockfile: use tmpfile API to handle file cleanup

Now that the tmpfile API implements all of our features
(plus the "active" flag described in the previous commit),
we can drop the duplicated code, and just put a "struct
tmpfile" into our "struct lock_file".

Most of the changes are mechanical, as we now need to refer
to "lk->tmp.filename" instead of "lk->filename". Since we
don't need any additional fields beyond that "struct
tmpfile" provides, we could instead just convert all "struct
lock_file" into "struct tmpfile" (or even hide it behind a
typedef).  However, that would be similarly disruptive (we
would not have to change member access, but we would have to
change many function signatures), and it would not leave any
room for additional lock-specific fields to be added later.
diff: check error code of close() when writing tempfiles

When we write a tempfile to disk for textconv or an external
diff, we carefully check that we are able to write the full
content to disk before invoking the sub-program. However, we
did not check the return value of close(), meaning that the
file might not have been fully written (e.g., on a networked
filesystem), meaning that the sub-program may have seen an
incomplete version of the file.
diff: use tmpfile API for temporary file cleanup

This reduces code duplication and gives us extra safety
features (like owner pid checks and removal in the proper
order for signal-race safety).

Furthermore, since we no longer need to maintain a global
list of files to clean up (tmpfile handles this itself), we
can do away with the ugly claim_tempfile system, and just
use a static tmpfile in each function which needs one.