Merge branch 'en/fast-import-merge-doc'

Doc update.

* en/fast-import-merge-doc:
  git-fast-import.txt: clarify that multiple merge commits are allowed

Merge branch 'jk/perf-no-dups'

Test & perf scripts must use unique numeric prefix, but a pair
shared the same number, which is fixed here.

* jk/perf-no-dups:
  t/perf: rename duplicate-numbered test script

Merge branch 'rs/nedalloc-fixlets'

Compilation fix.

* rs/nedalloc-fixlets:
  nedmalloc: avoid compiler warning about unused value
  nedmalloc: do assignments only after the declaration section

Merge branch 'sg/show-failed-test-names'

The first line of verbose output from each test piece now carries
the test name and number to help scanning with eyeballs.

* sg/show-failed-test-names:
  tests: show the test name and number at the start of verbose output
  t0000-basic: use realistic test script names in the verbose tests

Merge branch 'sg/commit-graph-validate'

The code to write commit-graph over given commit object names has
been made a bit more robust.

* sg/commit-graph-validate:
  commit-graph: error out on invalid commit oids in 'write --stdin-commits'
  commit-graph: turn a group of write-related macro flags into an enum
  t5318-commit-graph: use 'test_expect_code'

Merge branch 'vn/restore-empty-ita-corner-case-fix'

"git checkout" and "git restore" to re-populate the index from a
tree-ish (typically HEAD) did not work correctly for a path that
was removed and then added again with the intent-to-add bit, when
the corresponding working tree file was empty.  This has been
corrected.

* vn/restore-empty-ita-corner-case-fix:
  restore: add test for deleted ita files
  checkout.c: unstage empty deleted ita files

Merge branch 'sc/pack-refs-deletion-racefix'

"git pack-refs" can lose refs that are created while running, which
is getting corrected.

* sc/pack-refs-deletion-racefix:
  pack-refs: always refresh after taking the lock file

Merge branch 'sg/do-not-skip-non-httpd-tests'

Test fix.

* sg/do-not-skip-non-httpd-tests:
  t: warn against adding non-httpd-specific tests after sourcing 'lib-httpd'
  t5703: run all non-httpd-specific tests before sourcing 'lib-httpd.sh'
  t5510-fetch: run non-httpd-specific test before sourcing 'lib-httpd.sh'

Merge branch 'jk/tree-walk-overflow'

Codepaths to walk tree objects have been audited for integer
overflows and hardened.

* jk/tree-walk-overflow:
  tree-walk: harden make_traverse_path() length computations
  tree-walk: add a strbuf wrapper for make_traverse_path()
  tree-walk: accept a raw length for traverse_path_len()
  tree-walk: use size_t consistently
  tree-walk: drop oid from traverse_info
  setup_traverse_info(): stop copying oid

Merge branch 'sg/t5510-test-i18ngrep-fix'

Test fix.

* sg/t5510-test-i18ngrep-fix:
  t5510-fetch: fix negated 'test_i18ngrep' invocation

Merge branch 'mt/grep-submodules-working-tree'

"git grep --recurse-submodules" that looks at the working tree
files looked at the contents in the index in submodules, instead of
files in the working tree.

* mt/grep-submodules-working-tree:
  grep: fix worktree case in submodules

Git 2.23

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

Merge tag 'l10n-2.23.0-rnd2' of git://github.com/git-l10n/git-po

l10n-2.23.0-rnd2

l10n: zh_CN: for git v2.23.0 l10n round 1~2

Translate 128 new messages (4674t0f0u) for git 2.23.0.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

git-fast-import.txt: clarify that multiple merge commits are allowed

The grammar for commits used a '?' rather than a '*' on the `merge`
directive line, despite the fact that the code allows multiple `merge`
directives in order to support n-way merges.  In fact, elsewhere in
git-fast-import.txt there is an explicit declaration that "an unlimited
number of `merge` commands per commit are permitted by fast-import".
Fix the grammar to match the intent and implementation.

Reported-by: Joachim Klein <joachim.klein@automata.tools>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: de.po: Update German translation

Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com>
Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com>
Reviewed-by: Phillip Szelat <phillip.szelat@gmail.com>

t/perf: rename duplicate-numbered test script

There are two perf scripts numbered p5600, but with otherwise different
names ("clone-reference" versus "partial-clone"). We store timing
results in files named after the whole script, so internally we don't
get confused between the two. But "aggregate.perl" just prints the test
number for each result, giving multiple entries for "5600.3". It also
makes it impossible to skip one test but not the other with
GIT_SKIP_TESTS.

Let's renumber the one that appeared later (by date -- the source of the
problem is that the two were developed on independent branches). For the
non-perf test suite, our test-lint rule would have complained about this
when the two were merged, but t/perf never learned that trick.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of https://github.com/vnwildman/git

* 'master' of https://github.com/vnwildman/git:
  l10n: vi(4674t): Updated translation for Vietnamese

Merge branch 'update-italian-translation' of github.com:AlessandroMenti/git-po

* 'update-italian-translation' of github.com:AlessandroMenti/git-po:
  l10n: it.po: update the Italian localization for v2.23.0 round 2

Merge branch 'next' of https://github.com/ChrisADR/git-po

* 'next' of https://github.com/ChrisADR/git-po:
  l10n: es: 2.23.0 round 2

Sync with Git 2.22.1

doc: fix repeated words

Inspired by 21416f0a07 ("restore: fix typo in docs", 2019-08-03), I ran
"git grep -E '(\b[a-zA-Z]+) \1\b' -- Documentation/" to find other cases
where words were duplicated, e.g. "the the", and in most cases removed
one of the repeated words.

There were many false positives by this grep command, including
deliberate repeated words like "really really" or valid uses of "that
that" which I left alone, of course.

I also did not correct any of the legitimate, accidentally repeated
words in old RelNotes.

Signed-off-by: Mark Rushakoff <mark.rushakoff@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.22.1

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

.mailmap: update email address of Philip Oakley

My IEE 'home for life' email service is being withdrawn on 30 Sept 2019.
Replace with my new email domain.

I also have a secondary (backup) 'home for life' through
<philipoakley@dunelm.org.uk>.

Signed-off-by: Philip Oakley <philipoakley@iee.email>
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: it.po: update the Italian localization for v2.23.0 round 2

Signed-off-by: Alessandro Menti <alessandro.menti@alessandromenti.it>

l10n: vi(4674t): Updated translation for Vietnamese

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>

l10n: es: 2.23.0 round 2

Signed-off-by: Christopher Diaz Riveros <chrisadr@gentoo.org>

l10n: fr v2.23.0 round 2

Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>

l10n: git.pot: v2.23.0 round 2 (4 new, 6 removed)

Generate po/git.pot from v2.23.0-rc2 for git v2.23.0 l10n round 2.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Merge tag 'v2.23.0-rc2' of git://git./git/git

Git 2.23-rc2

* tag 'v2.23.0-rc2' of git://git.kernel.org/pub/scm/git/git: (63 commits)
  Git 2.23-rc2
  t0000: reword comments for "local" test
  t: decrease nesting in test_oid_to_path
  sha1-file: release strbuf after use
  test-dir-iterator: use path argument directly
  dir-iterator: release strbuf after use
  commit-graph: release strbufs after use
  l10n: reformat some localized strings for v2.23.0
  merge-recursive: avoid directory rename detection in recursive case
  commit-graph: fix bug around octopus merges
  restore: fix typo in docs
  doc: typo: s/can not/cannot/ and s/is does/does/
  Git 2.23-rc1
  log: really flip the --mailmap default
  RelNotes/2.23.0: fix a few typos and other minor issues
  RelNotes/2.21.1: typofix
  log: flip the --mailmap default unconditionally
  config: work around bug with includeif:onbranch and early config
  A few more last-minute fixes
  repack: simplify handling of auto-bitmaps and .keep files
  ...

l10n: bg.po: Updated Bulgarian translation (4674t)

Signed-off-by: Alexander Shopov <ash@kambanaria.org>

Merge branch 'cb/xdiff-no-system-includes-in-dot-c' into maint

Compilation fix.

* cb/xdiff-no-system-includes-in-dot-c:
  xdiff: remove duplicate headers from xpatience.c
  xdiff: remove duplicate headers from xhistogram.c
  xdiff: drop system includes in xutils.c

Merge branch 'jk/no-system-includes-in-dot-c' into maint

Compilation fix.

* jk/no-system-includes-in-dot-c:
  wt-status.h: drop stdio.h include
  verify-tag: drop signal.h include

Merge branch 'sg/fsck-config-in-doc' into maint

Doc update.

* sg/fsck-config-in-doc:
  Documentation/git-fsck.txt: include fsck.* config variables

Merge branch 'jk/xdiff-clamp-funcname-context-index' into maint

The internal diff machinery can be made to read out of bounds while
looking for --funcion-context line in a corner case, which has been
corrected.

* jk/xdiff-clamp-funcname-context-index:
  xdiff: clamp function context indices in post-image

Git 2.23-rc2

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

Merge branch 'bc/hash-independent-tests-part-4'

Test fix.

* bc/hash-independent-tests-part-4:
  t0000: reword comments for "local" test
  t: decrease nesting in test_oid_to_path

Merge branch 'rs/plug-strbuf-reak-in-read-alt-refs'

Leakfix.

* rs/plug-strbuf-reak-in-read-alt-refs:
  sha1-file: release strbuf after use

Merge branch 'mt/dir-iterator-updates'

Leakfix.

* mt/dir-iterator-updates:
  test-dir-iterator: use path argument directly
  dir-iterator: release strbuf after use

Merge branch 'ds/commit-graph-incremental'

Leakfix.

* ds/commit-graph-incremental:
  commit-graph: release strbufs after use

Merge branch 'ja/l10n-fixes'

A few messages have been updated to help localization better.

* ja/l10n-fixes:
  l10n: reformat some localized strings for v2.23.0

Merge branch 'en/disable-dir-rename-in-recursive-merge'

"merge-recursive" hit a BUG() when building a virtual merge base
detected a directory rename.

* en/disable-dir-rename-in-recursive-merge:
  merge-recursive: avoid directory rename detection in recursive case

Merge branch 'nd/switch-and-restore'

Docfix.

* nd/switch-and-restore:
  restore: fix typo in docs

Merge branch 'mr/doc-can-not-to-cannot'

Docfix.

* mr/doc-can-not-to-cannot:
  doc: typo: s/can not/cannot/ and s/is does/does/

Merge branch 'ds/commit-graph-octopus-fix'

commit-graph did not handle commits with more than two parents
correctly, which has been corrected.

* ds/commit-graph-octopus-fix:
  commit-graph: fix bug around octopus merges

t0000: reword comments for "local" test

Commit 01d3a526ad (t0000: check whether the shell supports the "local"
keyword, 2017-10-26) added a test to gather data on whether people run
the test suite with shells that don't support "local".

After almost two years, nobody has complained, and several other uses
have cropped up in test-lib-functions.sh. Let's declare it acceptable to
use.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t: decrease nesting in test_oid_to_path

t1410.3 ("corrupt and checks") fails when run using dash versions
before 0.5.8, with a cryptic message:

mv: cannot stat '.git/objects//e84adb2704cbd49549e52169b4043871e13432': No such file or directory

The function generating that path:

test_oid_to_path () {
echo "${1%${1#??}}/${1#??}"
}

which is supposed to produce a result like

12/3456789....

But a dash bug[*] causes it to instead expand to

/3456789...

The stream of symbols that makes up this function is hard for humans
to follow, too.  The complexity mostly comes from the repeated use of
the expression ${1#??} for the basename of the loose object.  Use a
variable instead --- nowadays, the dialect of shell used by Git
permits local variables, so this is cheap.

An alternative way to work around [*] is to remove the double-quotes
around test_oid_to_path's return value.  That makes the expression
easier for dash to read, but harder for humans.  Let's prefer the
rephrasing that's helpful for humans, too.

Noticed by building on Ubuntu trusty, which uses dash 0.5.7.

[*] Fixed by v0.5.8~13 ("[EXPAND] Propagate EXP_QPAT in subevalvar, 2013-08-23).

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1-file: release strbuf after use

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test-dir-iterator: use path argument directly

Avoid allocating and leaking a strbuf for holding a verbatim copy of the
path argument and pass the latter directly to dir_iterator_begin()
instead.

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dir-iterator: release strbuf after use

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit-graph: release strbufs after use

Signed-off-by: René Scharfe <l.s.r@web.de>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

nedmalloc: avoid compiler warning about unused value

Cast the evaluated value of the macro INITIAL_LOCK to void to instruct
the compiler that we're not interested in said value nor the following
warning:

In file included from compat/nedmalloc/nedmalloc.c:63:
compat/nedmalloc/malloc.c.h: In function ‘init_user_mstate’:
compat/nedmalloc/malloc.c.h:1706:62: error: right-hand operand of comma expression has no effect [-Werror=unused-value]
 1706 | #define INITIAL_LOCK(sl)      (memset(sl, 0, sizeof(MLOCK_T)), 0)
      |                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
compat/nedmalloc/malloc.c.h:5020:3: note: in expansion of macro ‘INITIAL_LOCK’
 5020 |   INITIAL_LOCK(&m->mutex);
      |   ^~~~~~~~~~~~

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

nedmalloc: do assignments only after the declaration section

Avoid the following compiler warning:

In file included from compat/nedmalloc/nedmalloc.c:63:
compat/nedmalloc/malloc.c.h: In function ‘pthread_release_lock’:
compat/nedmalloc/malloc.c.h:1759:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
 1759 |     volatile unsigned int* lp = &sl->l;
      |     ^~~~~~~~

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: reformat some localized strings for v2.23.0

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

merge-recursive: avoid directory rename detection in recursive case

Ever since commit 8c8e5bd6eb33 ("merge-recursive: switch directory
rename detection default", 2019-04-05), the default handling with
directory rename detection was to report a conflict and leave unstaged
entries in the index.  However, when creating a virtual merge base in
the recursive case, we absolutely need a tree, and the only way a tree
can be written is if we have no unstaged entries -- otherwise we hit a
BUG().

There are a few fixes possible here which at least fix the BUG(), but
none of them seem optimal for other reasons; see the comments with the
new testcase 13e in t6043 for details (which testcase triggered a BUG()
prior to this patch).  As such, just opt for a very conservative and
simple choice that is still relatively reasonable: have the recursive
case treat 'conflict' as 'false' for opt->detect_directory_renames.

Reported-by: Emily Shaffer <emilyshaffer@google.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: vi.po (4676t): Updated Vietnamese translation

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>

tests: show the test name and number at the start of verbose output

The verbose output of every test looks something like this:

  expecting success:
          echo content >file &&
          git add file &&
          git commit -m "add file"

  [master (root-commit) d1fbfbd] add file
   Author: A U Thor <author@example.com>
   1 file changed, 1 insertion(+)
   create mode 100644 file
  ok 1 - commit works

i.e. first an "expecting success" (or "checking known breakage") line
followed by the commands to be executed, then the output of those
comamnds, and finally an "ok"/"not ok" line containing the test name.
Note that the test's name is only shown at the very end.

With '-x' tracing enabled and/or in longer tests the verbose output
might be several screenfulls long, making it harder than necessary to
find where the output of the test with a given name starts (especially
when the outputs to different file descriptors are racing, and the
"expecting success"/command block arrives earlier than the "ok" line
of the previous test).

Print the test name at the start of the test's verbose output, i.e. at
the end of the "expecting success" and "checking known breakage"
lines, to make the start of a particular test a bit easier to
recognize.  Also print the test script and test case numbers, to help
those poor souls who regularly have to scan through the combined
verbose output of several test scripts.

So the dummy test above would start like this:

  expecting success of 9999.1 'commit works':
          echo content >file &&
  [...]

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0000-basic: use realistic test script names in the verbose tests

Our test scripts are named something like 't1234-command.sh', but the
script names used in 't0000-basic.sh' don't follow this naming
convention.  Normally this doesn't matter, because the test scripts
themselves don't care how they are called.  However, the next patch
will start to include the test number in the test's verbose output, so
the test script's name will matter in the two tests checking the
verbose output.

Update the tests 'test --verbose' and 'test --verbose-only' to follow
out test script naming convention.

Leave the other tests in 't0000' unchanged: changing the names of
their test scripts would be only pointless code churn.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit-graph: fix bug around octopus merges

In 1771be90 "commit-graph: merge commit-graph chains" (2019-06-18),
the method sort_and_scan_merged_commits() was added to merge the
commit lists of two commit-graph files in the incremental format.
Unfortunately, there was an off-by-one error in that method around
incrementing num_extra_edges, which leads to an incorrect offset
for the base graph chunk.

When we store an octopus merge in the commit-graph file, we store
the first parent in the normal place, but use the second parent
position to point into the "extra edges" chunk where the remaining
parents exist. This means we should be adding "num_parents - 1"
edges to this list, not "num_parents - 2". That is the basic error.

The reason this was not caught in the test suite is more subtle.
In 5324-split-commit-graph.sh, we test creating an octopus merge
and adding it to the tip of a commit-graph chain, then verify the
result. This _should_ have caught the problem, except that when
we load the commit-graph files we were overly careful to not fail
when the commit-graph chain does not match. This care was on
purpose to avoid race conditions as one process reads the chain
and another process modifies it. In such a case, the reading
process outputs the following message to stderr:

warning: commit-graph chain does not match

These warnings are output in the test suite, but ignored. By
checking the stderr of `git commit-graph verify` to include
the expected progress output, it will now catch this error.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit-graph: error out on invalid commit oids in 'write --stdin-commits'

While 'git commit-graph write --stdin-commits' expects commit object
ids as input, it accepts and silently skips over any invalid commit
object ids, and still exits with success:

  # nonsense
  $ echo not-a-commit-oid | git commit-graph write --stdin-commits
  $ echo $?
  0
  # sometimes I forgot that refs are not good...
  $ echo HEAD | git commit-graph write --stdin-commits
  $ echo $?
  0
  # valid tree OID, but not a commit OID
  $ git rev-parse HEAD^{tree} | git commit-graph write --stdin-commits
  $ echo $?
  0
  $ ls -l .git/objects/info/commit-graph
  ls: cannot access '.git/objects/info/commit-graph': No such file or directory

Check that all input records are indeed valid commit object ids and
return with error otherwise, the same way '--stdin-packs' handles
invalid input; see e103f7276f (commit-graph: return with errors during
write, 2019-06-12).

Note that it should only return with error when encountering an
invalid commit object id coming from standard input.  However,
'--reachable' uses the same code path to process object ids pointed to
by all refs, and that includes tag object ids as well, which should
still be skipped over.  Therefore add a new flag to 'enum
commit_graph_write_flags' and a corresponding field to 'struct
write_commit_graph_context', so we can differentiate between those two
cases.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit-graph: turn a group of write-related macro flags into an enum

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5318-commit-graph: use 'test_expect_code'

In 't5318-commit-graph.sh' the test 'close with correct error on bad
input' manually verifies the exit code of a 'git commit-graph write'
command.

Use 'test_expect_code' instead.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Acked-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

restore: fix typo in docs

Signed-off-by: William Chargin <wchargin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: typo: s/can not/cannot/ and s/is does/does/

"Can not" suggests one has the option to not do something, whereas
"cannot" more strongly suggests something is disallowed or impossible.

Noticed "can not", mistakenly used instead of "cannot" in git help
glossary, then ran git grep 'can not' and found many other instances.
Only files in the Documentation folder were modified.

'Can not' also occurs in some source code comments and some test
assertion messages, and there is an error message and translation "can
not move directory into itself" which I may fix and submit separately
from the documentation change.

Also noticed and fixed "is does" in git help fetch, but there are no
other occurrences of that typo according to git grep.

Signed-off-by: Mark Rushakoff <mark.rushakoff@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

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

* 'master' of https://github.com/Softcatala/git-po:
  l10n: Update Catalan translation

Merge branch 'update-italian-translation' of github.com:AlessandroMenti/git-po

* 'update-italian-translation' of github.com:AlessandroMenti/git-po:
  l10n: it.po: update the Italian translation for v2.23.0

l10n: Update Catalan translation

Signed-off-by: Jordi Mas <jmas@softcatala.org>

Git 2.23-rc1

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

Merge branch 'sg/fsck-config-in-doc'

Doc update.

* sg/fsck-config-in-doc:
  Documentation/git-fsck.txt: include fsck.* config variables

Merge branch 'js/visual-studio'

Support building Git with Visual Studio

The bits about .git/branches/* have been dropped from the series.
We may want to drop the support for it, but until that happens, the
tests should rely on the existence of the support to pass.

* js/visual-studio: (23 commits)
  git: avoid calling aliased builtins via their dashed form
  bin-wrappers: append `.exe` to target paths if necessary
  .gitignore: ignore Visual Studio's temporary/generated files
  .gitignore: touch up the entries regarding Visual Studio
  vcxproj: also link-or-copy builtins
  msvc: add a Makefile target to pre-generate the Visual Studio solution
  contrib/buildsystems: add a backend for modern Visual Studio versions
  contrib/buildsystems: handle options starting with a slash
  contrib/buildsystems: also handle -lexpat
  contrib/buildsystems: handle libiconv, too
  contrib/buildsystems: handle the curl library option
  contrib/buildsystems: error out on unknown option
  contrib/buildsystems: optionally capture the dry-run in a file
  contrib/buildsystems: redirect errors of the dry run into a log file
  contrib/buildsystems: ignore gettext stuff
  contrib/buildsystems: handle quoted spaces in filenames
  contrib/buildsystems: fix misleading error message
  contrib/buildsystems: ignore irrelevant files in Generators/
  contrib/buildsystems: ignore invalidcontinue.obj
  Vcproj.pm: urlencode '<' and '>' when generating VC projects
  ...

Merge branch 'jc/log-mailmap-flip-defaults'

Hotfix for making "git log" use the mailmap by default.

* jc/log-mailmap-flip-defaults:
  log: really flip the --mailmap default
  log: flip the --mailmap default unconditionally

Merge branch 'js/early-config-with-onbranch'

The recently added [includeif "onbranch:branch"] feature does not
work well with an early config mechanism, as it attempts to find
out what branch we are on before we even haven't located the git
repository.  The inclusion during early config scan is ignored to
work around this issue.

* js/early-config-with-onbranch:
  config: work around bug with includeif:onbranch and early config

restore: add test for deleted ita files

`git restore --staged` uses the same machinery as `git checkout HEAD`,
so there should be a similar test case for "restore" as the existing
test case for "checkout" with deleted ita files.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Varun Naik <vcnaik94@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

checkout.c: unstage empty deleted ita files

It is possible to delete a committed file from the index and then add it
as intent-to-add. After `git checkout HEAD <pathspec>`, the file should
be identical in the index and HEAD. The command already works correctly
if the file has contents in HEAD. This patch provides the desired
behavior even when the file is empty in HEAD.

`git checkout HEAD <pathspec>` calls tree.c:read_tree_1(), with fn
pointing to checkout.c:update_some(). update_some() creates a new cache
entry but discards it when its mode and oid match those of the old
entry. A cache entry for an ita file and a cache entry for an empty file
have the same oid. Therefore, an empty deleted ita file previously
passed both of these checks, and the new entry was discarded, so the
file remained unchanged in the index. After this fix, if the file is
marked as ita in the cache, then we avoid discarding the new entry and
add the new entry to the cache instead.

This change should not affect newly added ita files. For those, inside
tree.c:read_tree_1(), tree_entry_interesting() returns
entry_not_interesting, so fn is never called.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Varun Naik <vcnaik94@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pack-refs: always refresh after taking the lock file

When a packed ref is deleted, the whole packed-refs file is
rewritten to omit the ref that no longer exists. However if another
gc command is running and calls `pack-refs --all` simultaneously,
there is a chance that a ref that was just updated lose the newly
created commits.

Through these steps, losing commits on newly updated refs can be
demonstrated:

  # step 1: compile git without `USE_NSEC` option
  Some kernel releases do enable it by default while some do
  not. And if we compile git without `USE_NSEC`, it will be easier
  demonstrated by the following steps.

  # step 2: setup a repository and add the first commit
  git init repo &&
  (cd repo &&
   git config core.logallrefupdates true &&
   git commit --allow-empty -m foo)

  # step 3: in one terminal, repack the refs repeatedly
  cd repo &&
  while true
  do
    git pack-refs --all
  done

  # step 4: in another terminal, simultaneously update the
  # master with update-ref, and create and delete an
  # unrelated ref also with update-ref
  cd repo &&
  while true
  do
    us=$(git commit-tree -m foo -p HEAD HEAD^{tree}) &&
    git update-ref refs/heads/newbranch $us &&
    git update-ref refs/heads/master $us &&
    git update-ref -d refs/heads/newbranch &&
    them=$(git rev-parse master) &&
    if test "$them" != "$us"
    then
      echo >&2 "lost commit: $us"
      exit 1
    fi
    # eye candy
    printf .
  done

Though we have the packed-refs lock file and loose refs lock
files to avoid updating conflicts, a ref will lost its newly
commits if racy stat-validity of `packed-refs` file happens
(which is quite same as the racy-git described in
`Documentation/technical/racy-git.txt`), the following
specific set of operations demonstrates the problem:

  1. Call `pack-refs --all` to pack all the loose refs to
     packed-refs, and let say the modify time of the
     packed-refs is DATE_M.

  2. Call `update-ref` to update a new commit to master while
     it is already packed.  the old value (let us call it
     OID_A) remains in the packed-refs file and write the new
     value (let us call it OID_B) to $GIT_DIR/refs/heads/master.

  3. Call `update-ref -d` within the same DATE_M from the 1th
     step to delete a different ref newbranch which is packed
     in the packed-refs file. It check newbranch's oid from
     packed-refs file without locking it.

     Meanwhile it keeps a snapshot of the packed-refs file in
     memory and record the file's attributes with the snapshot.
     The oid of master in the packed-refs's snapshot is OID_A.

  4. Call a new `pack-refs --all` to pack the loose refs, the
     oid of master in packe-refs file is OID_B, and the loose
     refs $GIT_DIR/refs/heads/master is removed. Let's say
     the `pack-refs --all` is very quickly done and the new
     packed-refs file's modify time is still DATE_M, and it
     has the same file size, even the same inode.

  5. 3th step now goes on after checking the newbranch, it
     begin to rewrite the packed-refs file. After get the
     lock file of packed-ref file, it checks it's on-disk
     file attributes with the snapshot, suck as the timestamp,
     the file size and the inode value. If they are both the
     same values, and the snapshot is not refreshed.

     Because the loose ref of master is removed by 4th step,
     `update-ref -d` will updates the new packed-ref to disk
     which contains master with the oid OID_A. So now the
     newly commit OID_B of master is lost.

The best path forward is just always refreshing after take
the lock file of `packed-refs` file. Traditionally we avoided
that because refreshing it implied parsing the whole file.
But these days we mmap it, so it really is just an extra
open()/mmap() and a quick read of the header. That doesn't seem
like an outrageous cost to pay when we're already taking the lock.

Signed-off-by: Sun Chao <sunchao9@huawei.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Sun Chao <sunchao9@huawei.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

log: really flip the --mailmap default

Update the docs, test the interaction between the new default,
configuration and command line option, in addition to actually
flipping the default.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t: warn against adding non-httpd-specific tests after sourcing 'lib-httpd'

We have a couple of test scripts that are not completely
httpd-specific, but do run a few httpd-specific tests at the end.
These test scripts source 'lib-httpd.sh' somewhere mid-script, which
then skips all the rest of the test script if the dependencies for
running httpd tests are not fulfilled.

As the previous two patches in this series show, already on two
occasions non-httpd-specific tests were appended at the end of such
test scripts, and, consequently, they were skipped as well when httpd
tests couldn't be run.

Add a comment at the end of these test scripts to warn against adding
non-httpd-specific tests at the end, in the hope that they will help
prevent similar issues in the future.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tree-walk: harden make_traverse_path() length computations

The make_traverse_path() function isn't very careful about checking its
output buffer boundaries. In fact, it doesn't even _know_ the size of
the buffer it's writing to, and just assumes that the caller used
traverse_path_len() correctly. And even then we assume that our
traverse_info.pathlen components are all correct, and just blindly write
into the buffer.

Let's improve this situation a bit:

  - have the caller pass in their allocated buffer length, which we'll
    check against our own computations

  - check for integer underflow as we do our backwards-insertion of
    pathnames into the buffer

  - check that we do not run out items in our list to traverse before
    we've filled the expected number of bytes

None of these should be triggerable in practice (especially since our
switch to size_t everywhere in a previous commit), but it doesn't hurt
to check our assumptions.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tree-walk: add a strbuf wrapper for make_traverse_path()

All but one of the callers of make_traverse_path() allocate a new heap
buffer to store the path. Let's give them an easy way to write to a
strbuf, which saves them from computing the length themselves (which is
especially tricky when they want to add to the path). It will also make
it easier for us to change the make_traverse_path() interface in a
future patch to improve its bounds-checking.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tree-walk: accept a raw length for traverse_path_len()

We take a "struct name_entry", but only care about the length of the
path name. Let's just take that length directly, making it easier to use
the function from callers that sometimes do not have a name_entry at
all.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tree-walk: use size_t consistently

We store and manipulate the cumulative traverse_info.pathlen as an
"int", which can overflow when we are fed ridiculously long pathnames
(e.g., ones at the edge of 2GB or 4GB, even if the individual tree entry
names are smaller than that). The results can be confusing, though
after some prodding I was not able to use this integer overflow to cause
an under-allocated buffer.

Let's consistently use size_t to generate and store these, and make
sure our addition doesn't overflow.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5703: run all non-httpd-specific tests before sourcing 'lib-httpd.sh'

't5703-upload-pack-ref-in-want.sh' sources 'lib-httpd.sh' near the end
to run a couple of httpd-specific tests, but 'lib-httpd.sh' skips all
the rest of the test script if the dependencies for running httpd
tests are not fulfilled.  However, the last six tests in 't5703' are
not httpd-specific, but they are skipped as well when httpd tests
can't be run.

Move these six tests earlier in the test script, before 'lib-httpd.sh'
is sourced, so they will be run even when httpd tests aren't.  Note
that this is not merely a pure code movement, because the setup test
case for the httpd tests needed an additional 'rm -rf
"$LOCAL_PRISTINE"' to clean up a directory left behind by the moved
non-httpd-specific tests.

Also add a comment at the end of this test script to warn against
adding non-httpd-specific tests at the end, in the hope that it will
help prevent similar issues in the future.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5510-fetch: run non-httpd-specific test before sourcing 'lib-httpd.sh'

't5510-fetch.sh' sources 'lib-httpd.sh' near the end to run a
httpd-specific test, but 'lib-httpd.sh' skips all the rest of the test
script if the dependencies for running httpd tests are not fulfilled.
Alas, recently cdbd70c437 (fetch: add --[no-]show-forced-updates
argument, 2019-06-18) appended a non-httpd-specific test at the end,
and this test is then skipped as well when httpd tests can't be run.

Move this new test earlier in the test script, before 'lib-httpd.sh'
is sourced, so it will be run even when httpd tests aren't.

Also add a comment at the end of this test script to warn against
adding non-httpd-specific tests at the end, in the hope that it will
help prevent similar issues in the future.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jk/repack-silence-auto-bitmap-warning'

Squelch unneeded and misleading warnings from "repack" when the
command attempts to generate pack bitmaps without explicitly asked
for by the user.

* jk/repack-silence-auto-bitmap-warning:
  repack: simplify handling of auto-bitmaps and .keep files
  repack: silence warnings when auto-enabled bitmaps cannot be built
  t7700: clean up .keep file in bitmap-writing test

Merge branch 'jk/sort-iter-test-output'

* jk/sort-iter-test-output:
  t: sort output of hashmap iteration

Merge branch 'jc/dir-iterator-test-fix'

* jc/dir-iterator-test-fix:
  test-dir-iterator: do not assume errno values

Merge branch 'bc/hash-independent-tests-part-4'

Update to the tests to help SHA-256 transition continues.

* bc/hash-independent-tests-part-4:
  t2203: avoid hard-coded object ID values
  t1710: make hash independent
  t1007: remove SHA1 prerequisites
  t0090: make test pass with SHA-256
  t0027: make hash size independent
  t6030: make test work with SHA-256
  t5000: make hash independent
  t1450: make hash size independent
  t1410: make hash size independent
  t: add helper to convert object IDs to paths

RelNotes/2.23.0: fix a few typos and other minor issues

Fix the spelling of the new "--no-show-forced-updates" option that "git
fetch/pull" learned. Similarly, spell "--function-context" correctly and
fix a few typos, grammos and minor mistakes.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Sync with maint

* maint:
  RelNotes/2.21.1: typofix

RelNotes/2.21.1: typofix

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

log: flip the --mailmap default unconditionally

It turns out that being cautious to warn against upcoming default
change was an unpopular behaviour, and such a care can easily be
defeated by distro packagers to render it ineffective anyway.

Just flip the default, with only a mention in the release notes.

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

l10n: it.po: update the Italian translation for v2.23.0

Update the Italian translation for Git v2.23.0 (l10n round 1), as
well as adding some minor localization fixes.

Signed-off-by: Alessandro Menti <alessandro.menti@alessandromenti.it>

config: work around bug with includeif:onbranch and early config

Since 07b2c0eacac (config: learn the "onbranch:" includeIf condition,
2019-06-05), there is a potential catch-22 in the early config path: if
the `include.onbranch:` feature is used, Git assumes that the Git
directory has been initialized already. However, in the early config
code path that is not true.

One way to trigger this is to call the following commands in any
repository:

git config includeif.onbranch:refs/heads/master.path broken
git help -a

The symptom triggered by the `git help -a` invocation reads like this:

BUG: refs.c:1851: attempting to get main_ref_store outside of repository

Let's work around this, simply by ignoring the `includeif.onbranch:`
setting when parsing the config when the ref store has not been
initialized (yet).

Technically, there is a way to solve this properly: teach the refs
machinery to initialize the ref_store from a given gitdir/commondir pair
(which we _do_ have in the early config code path), and then use that in
`include_by_branch()`. This, however, is a pretty involved project, and
we're already in the feature freeze for Git v2.23.0.

Note: when calling above-mentioned two commands _outside_ of any Git
worktree (passing the `--global` flag to `git config`, as there is
obviously no repository config available), at the point when
`include_by_branch()` is called, `the_repository` is `NULL`, therefore
we have to be extra careful not to dereference it in that case.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

A few more last-minute fixes

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

Merge branch 'cb/xdiff-no-system-includes-in-dot-c'

Compilation fix.

* cb/xdiff-no-system-includes-in-dot-c:
  xdiff: remove duplicate headers from xpatience.c
  xdiff: remove duplicate headers from xhistogram.c
  xdiff: drop system includes in xutils.c

Merge branch 'jk/no-system-includes-in-dot-c'

Compilation fix.

* jk/no-system-includes-in-dot-c:
  wt-status.h: drop stdio.h include
  verify-tag: drop signal.h include

tree-walk: drop oid from traverse_info

As the previous commit shows, the presence of an oid in each level of
the traverse_info is confusing and ultimately not necessary. Let's drop
it to make it clear that it will not always be set (as well as convince
us that it's unused, and let the compiler catch any merges with other
branches that do add new uses).

Since the oid is part of name_entry, we'll actually stop embedding a
name_entry entirely, and instead just separately hold the pathname, its
length, and the mode.

This makes the resulting code slightly more verbose as we have to pass
those elements around individually. But it also makes it more clear what
each code path is going to use (and in most of the paths, we really only
care about the pathname itself).

A few of these conversions are noisier than they need to be, as they
also take the opportunity to rename "len" to "namelen" for clarity
(especially where we also have "pathlen" or "ce_len" alongside).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

setup_traverse_info(): stop copying oid

We assume that if setup_traverse_info() is passed a non-empty "base"
string, that string is pointing into a tree object and we can read the
object oid by skipping past the trailing NUL.

As it turns out, this is not true for either of the two calls, and we
may end up reading garbage bytes:

  1. In git-merge-tree, our base string is either empty (in which case
     we'd never run this code), or it comes from our traverse_path()
     helper. The latter overallocates a buffer by the_hash_algo->rawsz
     bytes, but then fills it with only make_traverse_path(), leaving
     those extra bytes uninitialized (but part of a legitimate heap
     buffer).

  2. In unpack_trees(), we pass o->prefix, which is some arbitrary
     string from the caller. In "git read-tree --prefix=foo", for
     instance, it will point to the command-line parameter, and we'll
     read 20 bytes past the end of the string.

Interestingly, tools like ASan do not detect (2) because the process
argv is part of a big pre-allocated buffer. So we're reading trash, but
it's trash that's probably part of the next argument, or the
environment.

You can convince it to fail by putting something like this at the
beginning of common-main.c's main() function:

  {
int i;
for (i = 0; i < argc; i++)
argv[i] = xstrdup_or_null(argv[i]);
  }

That puts the arguments into their own heap buffers, so running:

  make SANITIZE=address test

will find problems when "read-tree --prefix" is used (e.g., in t3030).

Doubly interesting, even with the hackery above, this does not fail
prior to ea82b2a085 (tree-walk: store object_id in a separate member,
2019-01-15). That commit switched setup_traverse_info() to actually
copying the hash, rather than simply pointing to it. That pointer was
always pointing to garbage memory, but that commit started actually
dereferencing the bytes, which is what triggers ASan.

That also implies that nobody actually cares about reading these oid
bytes anyway (or at least no path covered by our tests). And manual
inspection of the code backs that up (I'll follow this patch with some
cleanups that show definitively this is the case, but they're quite
invasive, so it's worth doing this fix on its own).

So let's drop the bogus hashcpy(), along with the confusing oversizing
in merge-tree.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

repack: simplify handling of auto-bitmaps and .keep files

Commit 7328482253 (repack: disable bitmaps-by-default if .keep files
exist, 2019-06-29) taught repack to prefer disabling bitmaps to
duplicating objects (unless bitmaps were asked for explicitly).

But there's an easier way to do this: if we keep passing the
--honor-pack-keep flag to pack-objects when auto-enabling bitmaps, then
pack-objects already makes the same decision (it will disable bitmaps
rather than duplicate). Better still, pack-objects can actually decide
to do so based not just on the presence of a .keep file, but on whether
that .keep file actually impacts the new pack we're making (so if we're
racing with a push or fetch, for example, their temporary .keep file
will not block us from generating bitmaps if they haven't yet updated
their refs).

And because repack uses the --write-bitmap-index-quiet flag, we don't
have to worry about pack-objects generating confusing warnings when it
does see a .keep file. We can confirm this by tweaking the .keep test to
check repack's stderr.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

repack: silence warnings when auto-enabled bitmaps cannot be built

Depending on various config options, a full repack may not be able to
build a reachability bitmap index (e.g., if pack.packSizeLimit forces us
to write multiple packs). In these cases pack-objects may write a
warning to stderr.

Since 36eba0323d (repack: enable bitmaps by default on bare repos,
2019-03-14), we may generate these warnings even when the user did not
explicitly ask for bitmaps. This has two downsides:

  - it can be confusing, if they don't know what bitmaps are

  - a daemonized auto-gc will write this to its log file, and the
    presence of the warning may suppress further auto-gc (until
    gc.logExpiry has elapsed)

Let's have repack communicate to pack-objects that the choice to turn on
bitmaps was not made explicitly by the user, which in turn allows
pack-objects to suppress these warnings.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>