l10n: de.po: translate 3 messages

Signed-off-by: Ralf Thielow <redacted>

l10n: zh_CN: various fixes on command arguments

Updated translations for Git 2.3.0 l10n round 2, and fixed various
translations for command arguments.

Signed-off-by: Jiang Xin <redacted>

Merge branch 'v2.3.0' of git://github.com/jnavila/git

* 'v2.3.0' of git://github.com/jnavila/git:
  l10n: fr.po v2.3.0 round 2

Merge branch 'master' of git://github.com/nafmo/git-l10n-sv

* 'master' of git://github.com/nafmo/git-l10n-sv:
  l10n: sv.po: Update Swedish translation (2298t0f0u)

l10n: vi.po(2298t): Updated 3 new strings

Signed-off-by: Tran Ngoc Quan <redacted>

l10n: sv.po: Update Swedish translation (2298t0f0u)

Signed-off-by: Peter Krefting <redacted>

l10n: fr.po v2.3.0 round 2

Signed-off-by: Jean-Noel Avila <redacted>

l10n: git.pot: v2.3.0 round 2 (3 updated)

Generate po/git.pot from v2.3.0-rc0-44-ga94655d for git v2.3.0 l10n
round 2.

Signed-off-by: Jiang Xin <redacted>

Merge branch 'master' of git://github.com/git-l10n/git-po

* 'master' of git://github.com/git-l10n/git-po:
  l10n: de.po: translate 13 new messages
  l10n: de.po: fix typo
  l10n: de.po: translate "track" as "versionieren"
  l10n: zh_CN: translations for git v2.3.0-rc0
  l10n: sv.po: Update Swedish translation (2298t0f0u)
  l10n: fr.po v2.3.0 round 1
  l10n: vi.po(2298t): Updated and change Plural-Forms
  l10n: git.pot: v2.3.0 round 1 (13 new, 11 removed)
  l10n: ca.po: various fixes

l10n: de.po: translate 13 new messages

Translate 13 new messages came from git.pot update in
beb691f (l10n: git.pot: v2.3.0 round 1 (13 new, 11 removed)).

Signed-off-by: Ralf Thielow <redacted>

l10n: de.po: fix typo

Signed-off-by: Ralf Thielow <redacted>

l10n: de.po: translate "track" as "versionieren"

Suggested-by: Torsten Bögershausen <redacted>
Signed-off-by: Ralf Thielow <redacted>

l10n: zh_CN: translations for git v2.3.0-rc0

Translate 13 new messages (2298t0f0u) for git v2.3.0-rc0.

Signed-off-by: Jiang Xin <redacted>

strbuf.h: group documentation for trim functions

The relationship between these makes more sense if you read
them as a group, which can help people who are looking for
the right function. Let's give them a single comment.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

strbuf.h: drop boilerplate descriptions of strbuf_split_*

The description of strbuf_split_buf says most of what
needs to be said for all of the split variants that take
strings, raw memory, etc. We have a boilerplate comment
above each that points to the first. This boilerplate
ends up making it harder to read, because it spaces out the
functions, which could otherwise be read as a group.

Let's drop the boilerplate completely, and mention the
variants in the top comment. This is perhaps slightly worse
for a hypothetical system which pulls the documentation for
each function out of the comment immediately preceding it.
But such a system does not yet exist, and anyway, the end
result of extracting the boilerplate comments would not lead
to a very easy-to-read result.  We would do better in the
long run to teach the extraction system about groups of
related functions.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

strbuf.h: reorganize api function grouping headers

The original API doc had something like:

    Functions
    ---------

    * Life cycle

      ... some life-cycle functions ...

    * Related to the contents of the buffer

      ... functions related to contents ....

    etc

This grouping can be hard to read in the comment sources,
given the "*" in the comment lines, and the amount of text
between each section.

Instead, let's make a flat list of groupings, and underline
each as a section header. That makes them stand out, and
eliminates the weird half-phrase of "Related to...". Like:

    Functions related to the contents of the buffer
    -----------------------------------------------

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

strbuf.h: format asciidoc code blocks as 4-space indent

This is much easier to read when the whole thing is stuffed
inside a comment block. And there is precedent for this
convention in markdown (and just in general ascii text).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

strbuf.h: drop asciidoc list formatting from API docs

Using a hanging indent is much more readable. This means we
won't format as asciidoc anymore, but since we don't have a
working system for extracting these comments anyway, it's
probably more important to just make the source readable.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

strbuf.h: unify documentation comments beginnings

The prior patch uses "/**" to denote "documentation"
comments that we pulled from api-strbuf.txt. Let's use a
consistent style for similar comments that were already in
strbuf.h.

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

strbuf.h: integrate api-strbuf.txt documentation

Some of strbuf is documented as comments above functions,
and some is separate in Documentation/technical/api-strbuf.txt.
This makes it annoying to find the appropriate documentation.
We'd rather have it all in one place, which means all in the
text document, or all in the header.

Let's choose the header as that place. Even though the
formatting is not quite as pretty, this keeps the
documentation close to the related code.  The hope is that
this makes it easier to find what you want (human-readable
comments are right next to the C declarations), and easier
for writers to keep the documentation up to date.

This is more or less a straight import of the text from
api-strbuf.txt into C comments, complete with asciidoc
formatting. The exceptions are:

 1. All comments created in this way are started with "/**"
    to indicate they are part of the API documentation. This
    may help later with extracting the text to pretty-print
    it.

 2. Function descriptions do not repeat the function name,
    as it is available in the context directly below.  So:

      `strbuf_add`::

          Add data of given length to the buffer.

    from api-strbuf.txt becomes:

      /**
       * Add data of given length to the buffer.
       */
      void strbuf_add(struct strbuf *sb, const void *, size_t);

    As a result, any block-continuation required in asciidoc
    for that list item was dropped in favor of straight
    blank-line paragraph (since it is not necessary when we
    are not in a list item).

 3. There is minor re-wording to integrate existing comments
    and api-strbuf text. In each case, I took whichever
    version was more descriptive, and eliminated any
    redundancies. In one case, for strbuf_addstr, the api
    documentation gave its inline definition; I eliminated
    this as redundant with the actual definition, which can
    be seen directly below the comment.

 4. The functions in the header file are re-ordered to match
    the ordering of the API documentation, under the
    assumption that more thought went into the grouping
    there.

Helped-by: Jonathan Nieder <redacted>
Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

tests: correct misuses of POSIXPERM

POSIXPERM requires that a later call to stat(2) (hence "ls -l")
faithfully reproduces what an earlier chmod(2) did.  Some
filesystems cannot satisify this.

SANITY requires that a file or a directory is indeed accessible (or
inaccessible) when its permission bits would say it ought to be
accessible (or inaccessible).  Running tests as root would lose this
prerequisite for obvious reasons.

Fix a few tests that misuse POSIXPERM.

t0061-run-command.sh has two uses of POSIXPERM.

 - One checks that an attempt to execute a file that is marked as
   unexecutable results in a failure with EACCES; I do not think
   having root-ness or any other capability that busts the
   filesystem permission mode bits will make you run an unexecutable
   file, so this should be left as-is.  The test does not have
   anything to do with SANITY.

 - The other one expects 'git nitfol' runs the alias when an
   alias.nitfol is defined and a directory on the PATH is marked as
   unreadable and unsearchable.  I _think_ the test tries to reject
   the alternative expectation that we want to refuse to run the
   alias because it would break "no alias may mask a command" rule
   if a file 'git-nitfol' exists in the unreadable directory but we
   cannot even determine if that is the case.  Under !SANITY that
   busts the permission bits, this test no longer checks that, so it
   must be protected with SANITY.

t1509-root-worktree.sh expects to be run on a / that is writable by
the user and sees if Git behaves "sensibly" when /.git is the
repository to govern a worktree that is the whole filesystem, and
also if Git behaves "sensibly" when / itself is a bare repository
with refs, objects, and friends (I find the definition of "behaves
sensibly" under these conditions hard to fathom, but it is a
different matter).

The implementation of the test is very much problematic.

 - It requires POSIXPERM, but it does not do chmod or checks modes
   in any way.

 - It runs "rm /*" and "rm -fr /refs /objects ..." in one of the
   tests, and also does "cd / && git init --bare".  If done on a
   live system that takes advantages of the "feature" being tested,
   these obviously will clobber the system.  But there is no guard
   against such a breakage.

 - It uses "test $UID = 0" to see rootness, which now should be
   spelled "! test_have_prereq NOT_ROOT"

Signed-off-by: Junio C Hamano <redacted>

t/lib-httpd: switch SANITY check for NOT_ROOT

The SANITY prerequisite is really about whether the
filesystem will respect the permissions we set, and being
root is only one part of that. But the httpd tests really
just care about not being root, as they are trying to avoid
weirdness in apache (see a1a3011 for details).

Let's switch out SANITY for a new NOT_ROOT prerequisite,
which will let us tweak SANITY more freely.

We implement NOT_ROOT by checking `id -u`, which is in POSIX
and seems to be available even on MSYS.  Note that we cannot
just call this "ROOT" and ask for "!ROOT". The possible
outcomes are:

  1. we know we are root

  2. we know we are not root

  3. we could not tell, because `id` was not available

We should conservatively treat (3) as "does not have the
prerequisite", which means that a naive negation would not
work.

Helped-by: Kyle J. McKay <redacted>
Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

"log --pretty" documentation: do not forget "tformat:"

We forgot to list "tformat:<string>" when enumerating possible
values that "--pretty=<format>" can take.  It was not described
that "--pretty='string with %s placeholder'" that is not understood
is DWIMmed as "--pretty=tformat:<that string>".

Further, it was unclear what "When omitted, defaults to 'medium'"
was meant.  Is it "When --pretty=<something> was not given at all",
or is it "When --pretty is given without =<something>"?  Clarify
that it is the latter.

Signed-off-by: Junio C Hamano <redacted>

CodingGuidelines: clarify C #include rules

Even though "advice.h" includes "git-compat-util.h", it is not
sensible to have it as the first #include and indirectly satisify
the "You must give git-compat-util.h a clean environment to set up
feature test macros before including any of the system headers are
included", which is the real requirement.

Because:

 - A command that interacts with the object store, config subsystem,
   the index, or the working tree cannot do anything without using
   what is declared in "cache.h";

 - A built-in command must be declared in "builtin.h", so anything
   in builtin/*.c must include it;

 - These two headers both include "git-compat-util.h" as the first
   thing; and

 - Almost all our *.c files (outside compat/ and borrowed files in
   xdiff/) need some Git-ness from "cache.h" to do something
   Git-ish.

let's explicitly specify that one of these three header files must
be the first thing that is included.

Any of our *.c file should include the header file that directly
declares what it uses, instead of relying on the fact that some *.h
file it includes happens to include another *.h file that declares
the necessary function or type.  Spell it out as another guideline
item.

Helped-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

shallow.c: make check_shallow_file_for_update() static

No external callers exist.

Signed-off-by: Junio C Hamano <redacted>

remote.c: make clear_cas_option() static

No external callers exist.

Signed-off-by: Junio C Hamano <redacted>

urlmatch.c: make match_urls() static

No external callers exist.

Signed-off-by: Junio C Hamano <redacted>

revision.c: make save_parents() and free_saved_parents() static

No external callers exist.

Signed-off-by: Junio C Hamano <redacted>

line-log.c: make line_log_data_init() static

No external callers exist.

Signed-off-by: Junio C Hamano <redacted>

pack-bitmap.c: make pack_bitmap_filename() static

Reviewed-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

prompt.c: remove git_getpass() nobody uses

This was whittled down to a compatibility wrapper around the more
flexible git_prompt() in 1cb0134f (refactor git_getpass into generic
prompt function, 2011-12-10), waiting for the final callers to go
away.  That happened in 791643a8 (imap-send: use git-credential,
2014-04-28) when imap-send learned to use the credential interface.

Reviewed-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

http.c: make finish_active_slot() and handle_curl_result() static

They used to be used directly by remote-curl.c for the smart-http
protocol. But they got wrapped by run_one_slot() in beed336 (http:
never use curl_easy_perform, 2014-02-18).  Any future users are
expected to follow that route.

Reviewed-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-svn: make it play nicely with submodules

It's a simple matter of opening the directory specified in the gitfile.

[ew: tweaked check to avoid open() on directories]

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Eric Wong <redacted>

Git::SVN: handle missing ref_id case correctly

ref_id should not match "refs/remotes/".

[ew: dropped initial hunk for GIT_SVN_ID at Ramkumar's request]

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Eric Wong <redacted>

l10n: sv.po: Update Swedish translation (2298t0f0u)

Signed-off-by: Peter Krefting <redacted>

t1050-large: generate large files without dd

For some unknown reason, the dd on my Windows box segfaults randomly,
but since recently, it does so much more often than it used to, which
makes running the test suite burdensome.

Use printf to write large files instead of dd. To emphasize that three
of the large blobs are exact copies, use cp to allocate them.

The new code makes the files a bit smaller, and they are not sparse
anymore, but the tests do not depend on these properties. We do not want
to use test-genrandom here (which is used to generate large files
elsewhere in t1050), so that the files can be compressed well (which
keeps the run-time short).

The files are now large text files, not binary files. But since they
are larger than core.bigfilethreshold they are diagnosed as binary
by Git. For this reason, the 'git diff' tests that check the output
for "Binary files differ" still pass.

Signed-off-by: Johannes Sixt <redacted>
Reviewed-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Fifth batch for 2.3 cycle

Hopefully this will be the final feature update for 2.3-rc1

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'po/doc-core-ignorestat'

* po/doc-core-ignorestat:
  doc: core.ignoreStat update, and clarify the --assume-unchanged effect
  doc: core.ignoreStat clarify the --assume-unchanged effect

Merge branch 'rc/for-each-ref-tracking'

* rc/for-each-ref-tracking:
  for-each-ref: always check stat_tracking_info()'s return value

Merge branch 'rh/autoconf-rhel3'

Build update for older RHEL.

* rh/autoconf-rhel3:
  configure.ac: check for HMAC_CTX_cleanup
  configure.ac: check for clock_gettime and CLOCK_MONOTONIC
  configure.ac: check 'tv_nsec' field in 'struct stat'

Merge branch 'ak/fewer-includes'

* ak/fewer-includes:
  cat-file: remove unused includes
  git.c: remove unnecessary #includes

Merge branch 'ak/doc-add-v-n-options'

* ak/doc-add-v-n-options:
  Documentation: list long options for -v and -n

Merge branch 'ak/show-branch-usage-string'

* ak/show-branch-usage-string:
  show-branch: line-wrap show-branch usage

Merge branch 'rh/test-color-avoid-terminfo-in-original-home'

We try to see if "tput" gives a useful result before switching TERM
to dumb and moving HOME to point to our fake location for stability
of the tests, and then use the command when coloring the output
from the tests, but there is no guarantee "tput" works after
switching HOME.

* rh/test-color-avoid-terminfo-in-original-home:
  test-lib.sh: do tests for color support after changing HOME
  test-lib: use 'test ...' instead of '[ ... ]'

Merge branch 'tf/prompt-preserve-exit-status'

Using the exit status of the last command in the prompt, e.g.
PS1='$(__git_ps1) $? ', did not work well because the helper
function stomped on the exit status.

* tf/prompt-preserve-exit-status:
  git-prompt: preserve value of $? in all cases

Merge branch 'rh/hide-prompt-in-ignored-directory'

* rh/hide-prompt-in-ignored-directory:
  git-prompt.sh: allow to hide prompt for ignored pwd
  git-prompt.sh: if pc mode, immediately set PS1 to a plain prompt

Merge branch 'mm/complete-rebase-autostash'

* mm/complete-rebase-autostash:
  git-completion: add --autostash for 'git rebase'

Merge branch 'aw/doc-smtp-ssl-cert-path'

A long overdue documentation update to match an age-old code
update.

* aw/doc-smtp-ssl-cert-path:
  correct smtp-ssl-cert-path description

Merge branch 'sp/subtree-doc'

* sp/subtree-doc:
  subtree: fix AsciiDoc list item continuation

Merge branch 'km/log-usage-string-i18n'

* km/log-usage-string-i18n:
  log.c: fix translation markings

Merge branch 'km/imap-send-libcurl-options'

Now imap-send learned to talk to the server using cURL library,
allow the same GIT_CURL_VERBOSE environment variable to control the
verbosity of the chattering.

* km/imap-send-libcurl-options:
  imap-send.c: set CURLOPT_USE_SSL to CURLUSESSL_TRY
  imap-send.c: support GIT_CURL_VERBOSE

Merge branch 'jk/prune-packed-server-info'

Fix recent breakage in Git 2.2 that started creating info/refs and
objects/info/packs files with permission bits tighter than user's
umask.

* jk/prune-packed-server-info:
  update-server-info: create info/* with mode 0666
  t1301: set umask in reflog sharedrepository=group test

Merge branch 'js/remote-add-with-insteadof'

"git remote add $name $URL" is now allowed when "url.$URL.insteadOf"
is already defined.

* js/remote-add-with-insteadof:
  Add a regression test for 'git remote add <existing> <same-url>'
  git remote: allow adding remotes agreeing with url.<...>.insteadOf

Document receive.advertiseatomic

This was missing in 1b70fe5d3054 (2015-01-07, receive-pack.c: negotiate
atomic push support) as I squashed the option in very late in the patch
series.

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

http-push: trim trailing newline from remote symref

When we fetch a symbolic ref file from the remote, we get
the whole string "ref: refs/heads/master\n", recognize it by
skipping past the "ref: ", and store the rest. We should
chomp the trailing newline.

This bug was introduced in ae021d8 (use skip_prefix to avoid
magic numbers, 2014-06-18), which did not notice that the
length computation fed to xmemdupz was quietly tweaked by 1
to account for this.

We can solve it by explicitly trimming the newline, which is
more obvious. Note that we use strbuf_rtrim here, which will
actually cut off any trailing whitespace, not just a single
newline. This is a good thing, though, as it makes our
parsing more liberal (and spaces are not valid in refnames
anyway).

Signed-off-by: Jeff King <redacted>
Tested-by: Kyle J. McKay <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-prompt: preserve value of $? in all cases

Signed-off-by: Tony Finch <redacted>
Reviewed-by: SZEDER Gábor <redacted>
Signed-off-by: Junio C Hamano <redacted>

standardize usage info string format

This patch puts the usage info strings that were not already in docopt-
like format into docopt-like format, which will be a litle easier for
end users and a lot easier for translators. Changes include:

- Placing angle brackets around fill-in-the-blank parameters
- Putting dashes in multiword parameter names
- Adding spaces to [-f|--foobar] to make [-f | --foobar]
- Replacing <foobar>* with [<foobar>...]

Signed-off-by: Alex Henrie <redacted>
Reviewed-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

cat-file: use "type" and "size" from outer scope

In cat_one_file(), "type" and "size" variables are defined in the
function scope, and then two variables of the same name are defined
in a block in one of the if/else statement, hiding the definitions
in the outer scope.

Because the values of the outer variables before the control enters
this scope, however, do not have to be preserved, we can remove
useless definitions of variables from the inner scope safely without
breaking anything.

Signed-off-by: Alexander Kuleshov <redacted>
Signed-off-by: Junio C Hamano <redacted>

l10n: fr.po v2.3.0 round 1

Signed-off-by: Jean-Noel Avila <redacted>

log: teach --invert-grep option

"git log --grep=<string>" shows only commits with messages that
match the given string, but sometimes it is useful to be able to
show only commits that do *not* have certain messages (e.g. "show
me ones that are not FIXUP commits").

Originally, we had the invert-grep flag in grep_opt, but because
"git grep --invert-grep" does not make sense except in conjunction
with "--files-with-matches", which is already covered by
"--files-without-matches", it was moved it to revisions structure.
To have the flag there expresses the function to the feature better.

When the newly inserted two tests run, the history would have commits
with messages "initial", "second", "third", "fourth", "fifth", "sixth"
and "Second", committed in this order.  The commits that does not match
either "th" or "Sec" is "second" and "initial". For the case insensitive
case only "initial" matches.

Signed-off-by: Christoph Junghans <redacted>
Signed-off-by: Junio C Hamano <redacted>

blame.c: fix garbled error message

The helper functions prepare_final() and prepare_initial() return a
pointer to a string that is a member of an object in the revs->pending
array. This array is later rebuilt when running prepare_revision_walk()
which potentially transforms the pointer target into a bogus string. Fix
this by maintaining a copy of the original string.

Signed-off-by: Lukas Fleischer <redacted>
Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

use xstrdup_or_null to replace ternary conditionals

This replaces "x ? xstrdup(x) : NULL" with xstrdup_or_null(x).
The change is fairly mechanical, with the exception of
resolve_refdup, which can eliminate a temporary variable.

There are still a few hits grepping for "?.*xstrdup", but
these are of slightly different forms and cannot be
converted (e.g., "x ? xstrdup(x->foo) : NULL").

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

builtin/commit.c: use xstrdup_or_null instead of envdup

The only reason for envdup to be its own function is that we
have to save the result in a temporary string. With
xstrdup_or_null, we can feed the result of getenv()
directly.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

builtin/apply.c: use xstrdup_or_null instead of null_strdup

This file had its own identical helper that predates
xstrdup_or_null. Let's use the global one to avoid
repetition.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-compat-util: add xstrdup_or_null helper

It's a common idiom to duplicate a string if it is non-NULL,
or pass a literal NULL through. This is already a one-liner
in C, but you do have to repeat the name of the string
twice. So if there's a function call, you must write:

  const char *x = some_fun(...);
  return x ? xstrdup(x) : NULL;

instead of (with this patch) just:

  return xstrdup_or_null(some_fun(...));

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

l10n: vi.po(2298t): Updated and change Plural-Forms

Signed-off-by: Tran Ngoc Quan <redacted>

l10n: git.pot: v2.3.0 round 1 (13 new, 11 removed)

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

Signed-off-by: Jiang Xin <redacted>

Merge branch 'master' of git://github.com/alexhenrie/git-po

* 'master' of git://github.com/alexhenrie/git-po:
  l10n: ca.po: various fixes

git-gui: reinstate support for Tcl 8.4

Tcl 8.5 introduced an extended vsatisfies syntax that is not
supported by Tcl 8.4.

Since only Tcl 8.4 is required this presents a problem.

The extended syntax was used starting with Git 2.0.0 in commit
b3f0c5c0 (git-gui: tolerate major version changes when comparing the
git version, 2014-05-17), so that a major version change would still
satisfy the condition.

However, what we really want is just a basic version compare, so use
vcompare instead to restore compatibility with Tcl 8.4.

Signed-off-by: Kyle J. McKay <redacted>
Signed-off-by: Junio C Hamano <redacted>
Signed-off-by: Pat Thoyts <redacted>

doc: core.ignoreStat update, and clarify the --assume-unchanged effect

The assume-unchanged bit, and consequently core.ignoreStat, can be
misunderstood. Be assertive about the expectation that file changes should
notified to Git.

Overhaul the general wording thus:
    1. direct description of what is ignored given first.
    2. example instruction of the user manual action required.
    3. use sideways indirection for assume-unchanged and update-index
       references.
    4. add a 'normally' to give leeway for the change detection.

Signed-off-by: Philip Oakley <redacted>
Signed-off-by: Junio C Hamano <redacted>

for-each-ref: always check stat_tracking_info()'s return value

The code handling %(upstream:track) and %(upstream:trackshort)
assumed that it always had a valid branch that had been sanitized
earlier in populate_value(), and thus did not check the return value
of the call to stat_tracking_info().

While there is indeed some sanitization code that basically
corresponds to stat_tracking_info() returning 0 (no base branch
set), the function can also return -1 when the base branch did exist
but has since then been deleted.

In this case, num_ours and num_theirs had undefined values and a
call to `git for-each-ref --format="%(upstream:track)"` could print
spurious values such as

  [behind -111794512]
  [ahead 38881640, behind 5103867]

even for repositories with one single commit.

Verify stat_tracking_info()'s return value and do not print anything
if it returns -1. This behavior also matches the documentation ("has
no effect if the ref does not have tracking information associated
with it").

Helped-by: Eric Sunshine <redacted>
Helped-by: Jeff King <redacted>
Signed-off-by: Raphael Kubo da Costa <redacted>
Signed-off-by: Junio C Hamano <redacted>

Git 2.3.0-rc0

Signed-off-by: Junio C Hamano <redacted>

Sync with 2.2.2

Git 2.2.2

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'jk/read-packed-refs-without-path-max' into maint

* jk/read-packed-refs-without-path-max:
  read_packed_refs: use skip_prefix instead of static array
  read_packed_refs: pass strbuf to parse_ref_line
  read_packed_refs: use a strbuf for reading lines

Merge branch 'mg/add-ignore-errors' into maint

* mg/add-ignore-errors:
  add: ignore only ignored files

Merge branch 'mh/find-uniq-abbrev' into maint

* mh/find-uniq-abbrev:
  sha1_name: avoid unnecessary sha1 lookup in find_unique_abbrev

Merge branch 'jk/approxidate-avoid-y-d-m-over-future-dates' into maint

* jk/approxidate-avoid-y-d-m-over-future-dates:
  approxidate: allow ISO-like dates far in the future
  pass TIME_DATE_NOW to approxidate future-check

Merge branch 'rw/apply-does-not-take-ignore-date' into maint

* rw/apply-does-not-take-ignore-date:
  git-am.txt: --ignore-date flag is not passed to git-apply

Merge branch 'jk/for-each-reflog-ent-reverse' into maint

* jk/for-each-reflog-ent-reverse:
  for_each_reflog_ent_reverse: turn leftover check into assertion
  for_each_reflog_ent_reverse: fix newlines on block boundaries

Merge branch 'bc/fetch-thin-less-aggressive-in-normal-repository'

Earlier we made "rev-list --object-edge" more aggressively list the
objects at the edge commits, in order to reduce number of objects
fetched into a shallow repository, but the change affected cases
other than "fetching into a shallow repository" and made it
unusably slow (e.g. fetching into a normal repository should not
have to suffer the overhead from extra processing).  Limit it to a
more specific case by introducing --objects-edge-aggressive, a new
option to rev-list.

* bc/fetch-thin-less-aggressive-in-normal-repository:
  pack-objects: use --objects-edge-aggressive for shallow repos
  rev-list: add an option to mark fewer edges as uninteresting
  Documentation: add missing article in rev-list-options.txt

Merge branch 'sb/doc-submitting-patches-keep-notes'

* sb/doc-submitting-patches-keep-notes:
  SubmittingPatches: explain rationale for using --notes with format-patch

Merge branch 'rs/simplify-transport-get'

* rs/simplify-transport-get:
  transport: simplify duplicating a substring in transport_get() using xmemdupz()

Merge branch 'rs/simplify-parsing-commit-tree-S'

* rs/simplify-parsing-commit-tree-S:
  commit-tree: simplify parsing of option -S using skip_prefix()

Merge branch 'rs/plug-strbuf-leak-in-merge'

* rs/plug-strbuf-leak-in-merge:
  merge: release strbuf after use in suggest_conflicts()

Merge branch 'rs/plug-strbuf-leak-in-lock-ref'

* rs/plug-strbuf-leak-in-lock-ref:
  refs: plug strbuf leak in lock_ref_sha1_basic()

Merge branch 'es/checkout-index-temp'

"git checkout-index --temp=$target $path" did not work correctly
for paths outside the current subdirectory in the project.

* es/checkout-index-temp:
  checkout-index: fix --temp relative path mangling
  t2004: demonstrate broken relative path printing
  t2004: standardize file naming in symlink test
  t2004: drop unnecessary write-tree/read-tree
  t2004: modernize style

Merge branch 'cc/bisect-rev-parsing'

The logic in "git bisect bad HEAD" etc. to avoid forcing the test
of the common ancestor of bad and good commits was broken.

* cc/bisect-rev-parsing:
  bisect: add test to check that revs are properly parsed
  bisect: parse revs before passing them to check_expected_revs()

gettext.h: add parentheses around N_ expansion if supported

The gettext N_ macro is used to mark strings for translation
without actually translating them.  At runtime the string is
expected to be passed to the gettext API for translation.

If two N_ macro invocations appear next to each other with only
whitespace (or nothing at all) between them, the two separate
strings will be marked for translation, but the preprocessor
will then silently combine the strings into one and at runtime
the string passed to gettext will not match the strings that
were translated so no translation will actually occur.

Avoid this by adding parentheses around the expansion of the
N_ macro so that instead of ending up with two adjacent strings
that are then combined by the preprocessor, two adjacent strings
surrounded by parentheses result instead which causes a compile
error so the mistake can be quickly found and corrected.

However, since these string literals are typically assigned to
static variables and not all compilers support parenthesized
string literal assignments, allow this to be controlled by the
Makefile with the default only enabled when the compiler is
known to support the syntax.

For now only __GNUC__ enables this by default which covers both
gcc and clang which should result in early detection of any
adjacent N_ macros.

Although the necessary tests make the affected files a bit less
elegant, the benefit of avoiding propagation of a translation-
marking error to all the translation teams thus creating extra
work for them when the error is eventually detected and fixed
would seem to outweigh the minor inelegance the additional
configuration tests introduce.

Helped-by: Junio C Hamano <redacted>
Signed-off-by: Kyle J. McKay <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation: list long options for -v and -n

Signed-off-by: Alexander Kuleshov <redacted>
Signed-off-by: Junio C Hamano <redacted>

cat-file: remove unused includes

 - "exec_cmd.h" became unnecessary at b931aa5a (Call builtin ls-tree
   in git-cat-file -p, 2006-05-26), when it changed an earlier code
   that delegated tree display to "ls-tree" via the run_command()
   API (hence needing "exec_cmd.h") to call cmd_ls_tree() directly.
   We should have removed the include in the same commit, but we
   forgot to do so.

 - "diff.h" was added at e5fba602 (textconv: support for cat_file,
   2010-06-15), together with "userdiff.h", but "userdiff.h" can be
   included without including "diff.h"; the header was unnecessary
   from the beginning.

 - "tag.h" and "tree.h" were necessary since 8e440259 (Use blob_,
   commit_, tag_, and tree_type throughout., 2006-04-02) to check
   the type of object by comparing typename with tree_type and
   tag_type (pointers to extern strings).

   21666f1a (convert object type handling from a string to a number,
   2007-02-26) made these <type>_type strings unnecessary, and it
   could have switched to include "object.h", which is necessary to
   use typename(), but it forgot to do so.  Because "tag.h" and
   "tree.h" include "object.h", it did not need to explicitly
   include "object.h" in order to start using typename() itself.

   We do not even have to include "object.h" after removing these
   two #includes, because "builtin.h" includes "commit.h" which in
   turn includes "object.h" these days.  This happened at 7b9c0a69
   (git-commit-tree: make it usable from other builtins,
   2008-07-01).

Signed-off-by: Alexander Kuleshov <redacted>
Signed-off-by: Junio C Hamano <redacted>

git.c: remove unnecessary #includes

"cache.h" and "commit.h" are already included via "builtin.h".

We started to include "quote.h" at 575ba9d6 (GIT_TRACE: show which
built-in/external commands are executed, 2006-06-25) that wanted to
use sq_quote_print().

When 6ce4e61f (Trace into a file or an open fd and refactor tracing
code., 2006-09-02) introduced trace.c API, the calls this file makes
to sq_quote_print() were replaced by calls to trace_argv_printf()
that are declared in "cache.h", which this file already includes.
We should have stopped including "quote.h" in that commit, but
forgot to do so.

Signed-off-by: Alexander Kuleshov <redacted>
Signed-off-by: Junio C Hamano <redacted>

configure.ac: check for HMAC_CTX_cleanup

OpenSSL version 0.9.6b and before defined the function HMAC_cleanup.
Newer versions define HMAC_CTX_cleanup.  Check for HMAC_CTX_cleanup and
fall back to HMAC_cleanup when the newer function is missing.

Signed-off-by: Reuben Hawkins <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

configure.ac: check for clock_gettime and CLOCK_MONOTONIC

Set or clear Makefile variables HAVE_CLOCK_GETTIME and
HAVE_CLOCK_MONOTONIC based upon results of the checks (overriding
default values from config.mak.uname).

CLOCK_MONOTONIC isn't available on RHEL3, but there are still RHEL3
systems being used in production.

Signed-off-by: Reuben Hawkins <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

configure.ac: check 'tv_nsec' field in 'struct stat'

Detect 'tv_nsec' field in 'struct stat' and set Makefile variable
NO_NSEC appropriately.

A side-effect of the above detection is that we also determine
whether 'stat.st_mtimespec' is available, so, as a bonus, set the
Makefile variable USE_ST_TIMESPEC, as well.

Signed-off-by: Reuben Hawkins <redacted>
Helped-by: Eric Sunshine <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

receive-pack: support push-to-checkout hook

When receive.denyCurrentBranch is set to updateInstead, a push that
tries to update the branch that is currently checked out is accepted
only when the index and the working tree exactly matches the
currently checked out commit, in which case the index and the
working tree are updated to match the pushed commit.  Otherwise the
push is refused.

This hook can be used to customize this "push-to-deploy" logic.  The
hook receives the commit with which the tip of the current branch is
going to be updated, and can decide what kind of local changes are
acceptable and how to update the index and the working tree to match
the updated tip of the current branch.

For example, the hook can simply run `git read-tree -u -m HEAD "$1"`
in order to emulate 'git fetch' that is run in the reverse direction
with `git push`, as the two-tree form of `read-tree -u -m` is
essentially the same as `git checkout` that switches branches while
keeping the local changes in the working tree that do not interfere
with the difference between the branches.

Signed-off-by: Junio C Hamano <redacted>

rerere: error out on autoupdate failure

We have been silently tolerating errors by returning early with an
error that the caller ignores since rerere.autoupdate was introduced
in v1.6.0-rc0~120^2 (2008-06-22).  So on error (for example if the
index is already locked), rerere can return success silently without
updating the index or with only some items in the index updated.

Better to treat such failures as a fatal error so the operator can
figure out what is wrong and fix it.

Signed-off-by: Jonathan Nieder <redacted>
Signed-off-by: Junio C Hamano <redacted>

show-branch: line-wrap show-branch usage

Signed-off-by: Alexander Kuleshov <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5543-atomic-push.sh: add basic tests for atomic pushes

This adds tests for the atomic push option.
The first four tests check if the atomic option works in
good conditions and the last three patches check if the atomic
option prevents any change to be pushed if just one ref cannot
be updated.

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

push.c: add an --atomic argument

Add a command line argument to the git push command to request atomic
pushes.

Signed-off-by: Ronnie Sahlberg <redacted>
Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>