Test improvement.

* sg/stress-test:
  test-lib: fix non-portable pattern bracket expressions
  test-lib: make '--stress' more bisect-friendly

Test fix.

* kd/t0028-octal-del-is-377-not-777:
  t0028: fix wrong octal values for BOM in setup

The code and tests assume that the system supplied iconv() would
always use BOM in its output when asked to encode to UTF-16 (or
UTF-32), but apparently some implementations output big-endian
without BOM.  A compile-time knob has been added to help such
systems (e.g. NonStop) to add BOM to the output to increase
portability.

* bc/utf16-portability-fix:
  utf8: handle systems that don't write BOM for UTF-16

* nd/fileno-may-be-macro:
  git-compat-util: work around fileno(fp) that is a macro

* nd/get-oid-with-context-returns-an-enum:
  get_oid_with_context(): match prototype and implementation

Code clean-up.

* rj/sequencer-sign-off-header-static:
  sequencer: make sign_off_header a file local symbol

The get_oid_with_context() function is declared to return an enum in
cache.h, but defined to return an int in sha1-name.c.  The compiler
notices this on AIX and rejects the build, since d1dd94b3 (Do not
print 'dangling' for cat-file in case of ambiguity - 2019-01-17) was
merged.

Return the correct type from the implementation to fix this.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

On various BSD's, fileno(fp) is implemented as a macro that directly
accesses the fields in the FILE * object, which breaks a function that
accepts a "void *fp" parameter and calls fileno(fp) and expect it to
work.

Work it around by adding a compile-time knob FILENO_IS_A_MACRO that
inserts a real helper function in the middle of the callchain.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

These are just some small fixes I noticed doing a complete read-through
(there are a few cases I left that are incomplete or abbreviated
sentences, but I think those are OK in this sort of bullet-list style).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In the feature that was eventually committed, "--date=auto" doesn't do
anything. It was generalized to "--date=auto:<format>".
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* nd/imap-send-typofix:
  imap-send.c: add a missing space in error message

Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When serializing UTF-16 (and UTF-32), there are three possible ways to
write the stream. One can write the data with a BOM in either big-endian
or little-endian format, or one can write the data without a BOM in
big-endian format.

Most systems' iconv implementations choose to write it with a BOM in
some endianness, since this is the most foolproof, and it is resistant
to misinterpretation on Windows, where UTF-16 and the little-endian
serialization are very common. For compatibility with Windows and to
avoid accidental misuse there, Git always wants to write UTF-16 with a
BOM, and will refuse to read UTF-16 without it.

However, musl's iconv implementation writes UTF-16 without a BOM,
relying on the user to interpret it as big-endian. This causes t0028 and
the related functionality to fail, since Git won't read the file without
a BOM.

Add a Makefile and #define knob, ICONV_OMITS_BOM, that can be set if the
iconv implementation has this behavior. When set, Git will write a BOM
manually for UTF-16 and UTF-32 and then force the data to be written in
UTF-16BE or UTF-32BE. We choose big-endian behavior here because the
tests use the raw "UTF-16" encoding, which will be big-endian when the
implementation requires this knob to be set.

Update the tests to detect this case and write test data with an added
BOM if necessary. Always write the BOM in the tests in big-endian
format, since all iconv implementations that omit a BOM must use
big-endian serialization according to the Unicode standard.

Preserve the existing behavior for systems which do not have this knob
enabled, since they may use optimized implementations, including
defaulting to the native endianness, which may improve performance.
Signed-off-by: Nbrian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The setup code uses octal values with printf to generate a BOM for
UTF-16/32 BE/LE. It specifically uses '\777' to emit a 0xff byte. This
relies on the fact that most shells truncate the value above 0o377.

Ash however interprets '\777' as '\77' + a literal '7', resulting in an
invalid BOM.

Fix this by using the proper value of 0xff: '\377'.
Signed-off-by: NKevin Daudt <me@ikke.info>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Use a '!' character to start a non-matching pattern bracket
expression, as specified by POSIX in Shell Command Language section
2.13.1 Patterns Matching a Single Character [1].

I used '^' instead in three places in the previous three commits, to
verify that the arguments of the '--stress=' and '--stress-limit='
options and the values of various '*_PORT' environment variables are
valid numbers.  With certain shells, at least with dash (upstream and
in Ubuntu 14.04) and mksh, this led to various undesired behaviors:

  # error message in case of a valid number
  $ ~/src/dash/src/dash ./t3903-stash.sh --stress=8
  error: --stress=<N> requires the number of jobs to run

  # not the expected error message
  $ ~/src/dash/src/dash ./t3903-stash.sh --stress=foo
  ./t3903-stash.sh: 238: test: Illegal number: foo

  # no error message at all?!
  $ mksh ./t3903-stash.sh --stress=foo
  $ echo $?
  0

Some other shells, e.g. Bash (even in posix mode), ksh, dash in Ubuntu
16.04 or later, are apparently happy to accept '^' just as well.

[1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13Signed-off-by: NSZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Commit d0aaa46f ("commit: move empty message checks to libgit",
2017-11-10) removes the last use of 'sign_off_header' outside of
the "sequencer.c" source file. Remove the extern declaration from
the header file and mark the definition of the symbol with the
static keyword.
Signed-off-by: NRamsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The NonStop platform needs this configuration item specified as
UnfortunatelyYes so that config directory files are correctly processed.
Signed-off-by: NRandall S. Becker <rsbecker@nexbridge.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJean-Noël Avila <jn.avila@free.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

Windows update.

* js/mingw-host-cpu:
  mingw: fix CPU reporting in `git version --build-options`

Update to the fuzzer.

* js/fuzz-commit-graph-update:
  object: fix leak of shallow_stat
  fuzz-commit-graph: initialize repo object

Doc update.

* kl/pretty-doc-markup-fix:
  doc: prevent overflowing <code> tag in rendered HTML

Build update.

* sg/ci-parallel-build:
  ci: clear and mark MAKEFLAGS exported just once
  ci: make sure we build Git parallel

A flakey "p4" test has been removed.

* ld/git-p4-remove-flakey-test:
  git-p4: remove ticket expiry test

For "rebase -i --reschedule-failed-exec", we do not want the "-y"
shortcut after all.

* js/rebase-i-redo-exec-fix:
  Revert "rebase: introduce a shortcut for --reschedule-failed-exec"

"git checkout [<tree-ish>] <pathspec>" started reporting the number
of paths that have got updated recently, but the same messages were
given when "git checkout -m <pathspec>" to unresolve conflicts that
have just been resolved.  The message now reports these unresolved
paths separately from the paths that are checked out from the index.

* nd/checkout-noisy-unmerge:
  checkout: count and print -m paths separately
  checkout: update count-checkouts messages

Some errors from the other side coming over smart HTTP transport
were not noticed, which has been corrected.

* js/smart-http-detect-remote-error:
  t5551: test server-side ERR packet
  remote-curl: tighten "version 2" check for smart-http
  remote-curl: refactor smart-http discovery

A new target "coverage-prove" to run the coverage test under
"prove" has been added.

* ds/coverage-prove:
  Makefile: add coverage-prove target

Test fix.

* tz/gpg-test-fix:
  t/lib-gpg: drop redundant killing of gpg-agent
  t/lib-gpg: quote path to ${GNUPGHOME}/trustlist.txt

Test fix.

* os/rebase-runs-post-checkout-hook:
  t5403: correct bash ambiguous redirect error in subtest 8 by quoting $GIT_DIR

Let's suppose that a test somehow becomes flaky between 'master' and
'pu', and tends to fail within the first 50 repetitions when run with
'--stress'.  In such a case we could use 'git bisect' to find the
culprit: if the test script fails with '--stress', then the commit is
definitely bad, but if it survives, say, 300 repetitions, then we could
consider it good with reasonable confidence.

Unfortunately, all this could only be done manually, because
'--stress' would run the test script repeatedly for all eternity on a
good commit, and it would exit with success even when it found a
failure on a bad commit.

So let's make '--stress' usable with 'git bisect run':

  - Make it exit with failure if a failure is found.

  - Add the '--stress-limit=<N>' option to repeat the test script
    at most N times in each of the parallel jobs, and exit with
    success when the limit is reached.

And then we could simply run something like:

  $ git bisect start origin/pu master
  $ git bisect run sh -c 'make && cd t &&
                          ./t1234-foo.sh --stress --stress-limit=300'

Sure, as a brand new feature it won't be any useful right now, but in
a release or three most cooking topics will already contain this, so
we could automatically bisect at least newly introduced flakiness.
Signed-off-by: NSZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The embedded blanks in the full path of the test git repository cased bash
to generate an ambugious redirect error.
Signed-off-by: NRandall S. Becker <rsbecker@nexbridge.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We have three email addresses for Clemens in our commit history, two of
them bouncing. Let's map the latter to the only one that still works.

Pointed out by Gábor Szeder.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In 53fc9993 ("gpg-interface t: extend the existing GPG tests with
GPGSM", 2018-07-20), the gpgconf call which kills gpg-agent was copied
from the existing gpg setup code.

The reason for killing gpg-agent is given in 29ff1f8f ("t: lib-gpg:
flush gpg agent on startup", 2017-07-20):

  When running gpg-relevant tests, a gpg-daemon is spawned for each
  GNUPGHOME used. This daemon may stay running after the test and cache
  file descriptors for the trash directories, even after the trash
  directory is removed. This leads to ENOENT errors when attempting to
  create files if tests are run multiple times.

  Add a cleanup script to force flushing the gpg-agent for that GNUPGHOME
  (if any) before setting up the GPG relevant-environment.

Killing gpg-agent once per test is sufficient.
Signed-off-by: NTodd Zullinger <tmz@pobox.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When gpgsm is installed, lib-gpg.sh attempts to update trustlist.txt to
relax the checking of some root certificate requirements.  The path to
"${GNUPGHOME}" contains spaces which cause an "ambiguous redirect"
warning when bash is used to run the tests:

  $ bash t7030-verify-tag.sh
  /git/t/lib-gpg.sh: line 66: ${GNUPGHOME}/trustlist.txt: ambiguous redirect
  ok 1 - create signed tags
  ok 2 # skip create signed tags x509  (missing GPGSM)
  ...

No warning is issued when using bash called as /bin/sh, dash, or mksh.

Quote the path to ensure the redirect works as intended and sets the
GPGSM prereq.  While we're here, drop the space after ">>".
Signed-off-by: NTodd Zullinger <tmz@pobox.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We cannot rely on `uname -m` in Git for Windows' SDK to tell us what
architecture we are compiling for, as we can compile both 32-bit and
64-bit `git.exe` from a 64-bit SDK, but the `uname -m` in that SDK will
always report `x86_64`.

So let's go back to our original design. And make it explicitly
Windows-specific.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In eee4502b ("shallow: migrate shallow information into the object
parser", 2018-05-17), we added a stat_validity pointer into the
parsed_object_pool struct, but did not add code to free this in
parsed_object_pool_clear(). This leak was found by fuzz-commit-graph.

Clear the struct and then free it in parsed_object_pool_clear() to
prevent the leak.
Signed-off-by: NJosh Steadmon <steadmon@google.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Various #DEFINE "constants" in commit-graph.c now depend on
the_hash_algo->rawsz, but this object must be initialized before it can
be used.
Signed-off-by: NJosh Steadmon <steadmon@google.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Add an apparently missing back-tick to fix a multi-line <code> section
on https://git-scm.com/docs/git-log which seems to have been caused by
commit 18fb7ffc ("pretty: respect color settings [...]", 2017-07-13).
Signed-off-by: NKatrin Leinweber <katrin.leinweber@uni-konstanz.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Clearing it once upfront, and turning all the assignment into
appending, would future-proof the code even more, to prevent
mistakes the previous one fixed from happening again.

Also, mark the variable exported just once at the beginning.  There
is no point in marking it exported repeatedly.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>