Improve the documentation of commands taking optional arguments in two
ways:

* Documents the behavior of '-O' (for grep) and '-S' (for commands
  creating commits) when used without the optional argument.

* Document the syntax of these options.

For the second point, the behavior is documented in gitcli(7), but it is
easy for users to miss, and hard for the same user to understand why e.g.
"git status -u no" does not work.

Document this explicitly in the documentation of each short option having
an optional argument: they are the most error prone since there is no '='
sign between the option and its argument.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Reviewed-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since the argument of -O, --open-file-in-pager is optional, it must be
stuck to the command. Reflect this in the documentation.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Reviewed-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Reviewed-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The experimental untracked-cache feature were buggy when paths with
a few levels of subdirectories are involved.

* dt/untracked-subdir:
  untracked cache: fix entry invalidation
  untracked-cache: fix subdirectory handling
  t7063: use --force-untracked-cache to speed up a bit
  untracked-cache: support sparse checkout

* br/svn-doc-include-paths-config:
  git-svn doc: mention "svn-remote.<name>.include-paths"

Error string fix.

* ah/submodule-typofix-in-error:
  git-submodule: remove extraneous space from error message

* js/maint-am-skip-performance-regression:
  am --skip/--abort: merge HEAD/ORIG_HEAD tree into index

f8da6801 (am --skip: support skipping while on unborn branch,
2015-06-06) introduced a performance regression to "git am --skip",
where it used "read-tree" to reconstruct the index from scratch
without reusing the cached stat information.

This is a backport of the corresponding patch to the builtin am in 2.6:
3ecc7040 (am --skip/--abort: merge HEAD/ORIG_HEAD tree into index,
2015-08-19).

Reportedly, it can make a huge difference on Windows, in one case a `git
rebase --skip` took 1m40s without, and 5s with, this patch.

cf. https://github.com/git-for-windows/git/issues/365Reported-and-suggested-by: NKim Gybels <kgybels@infogroep.be>
Acked-by: NPaul Tan <pyokagan@gmail.com>
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When we show "branch@{0}", we format into a fixed-size
buffer using sprintf. This can overflow if you have long
branch names. We can fix it by using a temporary strbuf.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This function assumes that the relative_base path passed
into it is no larger than PATH_MAX, and writes into a
fixed-size buffer. However, this path may not have actually
come from the filesystem; for example, add_submodule_odb
generates a path using a strbuf and passes it in. This is
hard to trigger in practice, though, because the long
submodule directory would have to exist on disk before we
would try to open its info/alternates file.

We can easily avoid the bug, though, by simply creating the
filename on the heap.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When we are loading a notes tree into our internal hash
table, we also collect any files that are clearly non-notes.
We format the name of the file into a PATH_MAX buffer, but
unlike true notes (which cannot be larger than a fanned-out
sha1 hash), these tree entries can be arbitrarily long,
overflowing our buffer.

We can fix this by switching to a strbuf. It doesn't even
cost us an extra allocation, as we can simply hand ownership
of the buffer over to the non-note struct.

This is of moderate security interest, as you might fetch
notes trees from an untrusted remote. However, we do not do
so by default, so you would have to manually fetch into the
notes namespace.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When unpack-trees wants to know whether a path will
overwrite anything in the working tree, we use lstat() to
see if there is anything there. But if we are going to write
"foo/bar", we can't just lstat("foo/bar"); we need to look
for leading prefixes (e.g., "foo"). So we use the lstat cache
to find the length of the leading prefix, and copy the
filename up to that length into a temporary buffer (since
the original name is const, we cannot just stick a NUL in
it).

The copy we make goes into a PATH_MAX-sized buffer, which
will overflow if the prefix is longer than PATH_MAX. How
this happens is a little tricky, since in theory PATH_MAX is
the biggest path we will have read from the filesystem. But
this can happen if:

  - the compiled-in PATH_MAX does not accurately reflect
    what the filesystem is capable of

  - the leading prefix is not _quite_ what is on disk; it
    contains the next element from the name we are checking.
    So if we want to write "aaa/bbb/ccc/ddd" and "aaa/bbb"
    exists, the prefix of interest is "aaa/bbb/ccc". If
    "aaa/bbb" approaches PATH_MAX, then "ccc" can overflow
    it.

So this can be triggered, but it's hard to do. In
particular, you cannot just "git clone" a bogus repo. The
verify_absent checks happen before unpack-trees writes
anything to the filesystem, so there are never any leading
prefixes during the initial checkout, and the bug doesn't
trigger. And by definition, these files are larger than
PATH_MAX, so writing them will fail, and clone will
complain (though it may write a partial path, which will
cause a subsequent "git checkout" to hit the bug).

We can fix it by creating the temporary path on the heap.
The extra malloc overhead is not important, as we are
already making at least one stat() call (and probably more
for the prefix discovery).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* ee/clean-test-fixes:
  t7300: fix broken && chains

"git init empty && git -C empty log" said "bad default revision 'HEAD'",
which was found to be a bit confusing to new users.

* jk/log-missing-default-HEAD:
  log: diagnose empty HEAD more clearly

The "interpret-trailers" helper mistook a multi-paragraph title of
a commit log message with a colon in it as the end of the trailer
block.

* cc/trailers-corner-case-fix:
  trailer: support multiline title
  trailer: retitle a test and correct an in-comment message
  trailer: ignore first line of message

When re-priming the cache-tree opportunistically while committing
the in-core index as-is, we mistakenly invalidated the in-core
index too aggressively, causing the experimental split-index code
to unnecessarily rewrite the on-disk index file(s).

* dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update:
  commit: don't rewrite shared index unnecessarily

"git archive" did not use zip64 extension when creating an archive
with more than 64k entries, which nobody should need, right ;-)?

* rs/archive-zip-many:
  archive-zip: support more than 65535 entries
  archive-zip: use a local variable to store the creator version
  t5004: test ZIP archives with many entries

Minor code cleanup.

* jc/calloc-pathspec:
  ps_matched: xcalloc() takes nmemb and then element size

* ss/fix-config-fd-leak:
  config: close config file handle in case of error

* sg/wt-status-header-inclusion:
  wt-status: move #include "pathspec.h" to the header

Doc updates for i18n.

* po/po-readme:
  po/README: Update directions for l10n contributors

* sg/t3020-typofix:
  t3020: fix typo in test description

Docfix.

* as/docfix-reflog-expire-unreachable:
  Documentation/config: fix inconsistent label on gc.*.reflogExpireUnreachable

The code in "multiple-worktree" support that attempted to recover
from an inconsistent state updated an incorrect file.

* nd/fixup-linked-gitdir:
  setup: update the right file in multiple checkouts

"git rev-list" does not take "--notes" option, but did not complain
when one is given.

* jk/rev-list-has-no-notes:
  rev-list: make it obvious that we do not support notes

Because the configuration system does not allow "alias.0foo" and
"pager.0foo" as the configuration key, the user cannot use '0foo'
as a custom command name anyway, but "git 0foo" tried to look these
keys up and emitted useless warnings before saying '0foo is not a
git command'.  These warning messages have been squelched.

* jk/fix-alias-pager-config-key-warnings:
  config: silence warnings for command names with invalid keys

Test updates for Windows.

* nd/dwim-wildcards-as-pathspecs:
  t2019: skip test requiring '*' in a file name non Windows

We rewrote one of the build scripts in Perl but this reimplements
in Bourne shell.

* sg/help-group:
  generate-cmdlist: re-implement as shell script

t1509 test that requires a dedicated VM environment had some
bitrot, which has been corrected.

* ps/t1509-chroot-test-fixup:
  tests: fix cleanup after tests in t1509-root-worktree
  tests: fix broken && chains in t1509-root-worktree

strbuf_read() used to have one extra iteration (and an unnecessary
strbuf_grow() of 8kB), which was eliminated.

* jh/strbuf-read-use-read-in-full:
  strbuf_read(): skip unnecessary strbuf_grow() at eof

The codepath to produce error messages had a hard-coded limit to
the size of the message, primarily to avoid memory allocation while
calling die().

* jk/long-error-messages:
  vreportf: avoid intermediate buffer
  vreportf: report to arbitrary filehandles