Merge branch 'en/ort-perf-batch-11'

Optimize out repeated rename detection in a sequence of mergy
operations.

* en/ort-perf-batch-11:
  merge-ort, diffcore-rename: employ cached renames when possible
  merge-ort: handle interactions of caching and rename/rename(1to1) cases
  merge-ort: add helper functions for using cached renames
  merge-ort: preserve cached renames for the appropriate side
  merge-ort: avoid accidental API mis-use
  merge-ort: add code to check for whether cached renames can be reused
  merge-ort: populate caches of rename detection results
  merge-ort: add data structures for in-memory caching of rename detection
  t6429: testcases for remembering renames
  fast-rebase: write conflict state to working tree, index, and HEAD
  fast-rebase: change assert() to BUG()
  Documentation/technical: describe remembering renames optimization
  t6423: rename file within directory that other side renamed

Merge branch 'jk/fetch-pack-v2-half-close-early'

"git fetch" over protocol v2 left its side of the socket open after
it finished speaking, which unnecessarily wasted the resource on
the other side.

* jk/fetch-pack-v2-half-close-early:
  fetch-pack: signal v2 server that we are done making requests

Merge branch 'ds/write-index-with-hashfile-api'

Use the hashfile API in the codepath that writes the index file to
reduce code duplication.

* ds/write-index-with-hashfile-api:
  read-cache: delete unused hashing methods
  read-cache: use hashfile instead of git_hash_ctx
  csum-file.h: increase hashfile buffer size
  hashfile: use write_in_full()

Merge branch 'jk/clone-clean-upon-transport-error'

Recent "git clone" left a temporary directory behind when the
transport layer returned an failure.

* jk/clone-clean-upon-transport-error:
  clone: clean up directory after transport_fetch_refs() failure

Merge branch 'ga/send-email-sendmail-cmd'

"git send-email" learned the "--sendmail-cmd" command line option
and the "sendemail.sendmailCmd" configuration variable, which is a
more sensible approach than the current way of repurposing the
"smtp-server" that is meant to name the server to instead name the
command to talk to the server.

* ga/send-email-sendmail-cmd:
  git-send-email: add option to specify sendmail command

Merge branch 'zh/ref-filter-atom-type'

The code to handle the "--format" option in "for-each-ref" and
friends made too many string comparisons on %(atom)s used in the
format string, which has been corrected by converting them into
enum when the format string is parsed.

* zh/ref-filter-atom-type:
  ref-filter: introduce enum atom_type
  ref-filter: add objectsize to used_atom

The first batch post Git 2.32

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

Merge branch 'ah/setup-extensions-message-i18n-fix'

Message update.

* ah/setup-extensions-message-i18n-fix:
  setup: split "extensions found" messages into singular and plural

Merge branch 'ah/fetch-reject-warning-grammofix'

Message update.

* ah/fetch-reject-warning-grammofix:
  fetch: improve grammar of "shallow roots" message

Merge branch 'jk/doc-color-pager'

The documentation for "color.pager" configuration variable has been
updated.

* jk/doc-color-pager:
  doc: explain the use of color.pager

Merge branch 'tl/fix-packfile-uri-doc'

Doc fix.

* tl/fix-packfile-uri-doc:
  packfile-uri.txt: fix blobPackfileUri description

Merge branch 'ry/clarify-fast-forward-in-glossary'

The description of "fast-forward" in the glossary has been updated.

* ry/clarify-fast-forward-in-glossary:
  docs: improve fast-forward in glossary content

Merge branch 'wm/rev-parse-die-i18n'

Quite a many die() messages in rev-parse haven't been marked for
translation.

* wm/rev-parse-die-i18n:
  rev-parse: mark die() messages for translation

Merge branch 'jc/clarify-revision-range'

Doc update.

* jc/clarify-revision-range:
  revisions(7): clarify that most commands take a single revision range

Merge branch 'ah/doc-describe'

Doc update.

* ah/doc-describe:
  describe-doc: clarify default length of abbreviation

Merge branch 'ah/submodule-helper-module-summary-parseopt'

Message update.

* ah/submodule-helper-module-summary-parseopt:
  submodule: use the imperative mood to describe the --files option

Merge branch 'ah/stash-usage-i18n-fix'

i18n update.

* ah/stash-usage-i18n-fix:
  stash: don't translate literal commands

Merge branch 'ah/merge-usage-i18n-fix'

i18n update.

* ah/merge-usage-i18n-fix:
  merge: don't translate literal commands

Merge branch 'jn/size-t-casted-to-off-t-fix'

Rewrite code that triggers undefined behaiour warning.

* jn/size-t-casted-to-off-t-fix:
  xsize_t: avoid implementation defined behavior when len < 0

Merge branch 'mt/parallel-checkout-with-padded-oidcpy'

The parallel checkout codepath did not initialize object ID field
used to talk to the worker processes in a futureproof way.

* mt/parallel-checkout-with-padded-oidcpy:
  parallel-checkout: send the new object_id algo field to the workers

Merge branch 'ef/mailinfo-short-name'

We historically rejected a very short string as an author name
while accepting a patch e-mail, which has been loosened.

* ef/mailinfo-short-name:
  mailinfo: don't discard names under 3 characters

Git 2.32

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

Merge tag 'l10n-2.32.0-rnd1.1' of git://github.com/git-l10n/git-po

l10n-2.32.0-rnd1.1

* tag 'l10n-2.32.0-rnd1.1' of git://github.com/git-l10n/git-po: (25 commits)
  l10n: es: 2.32.0 round 1
  l10n: zh_CN: for git v2.32.0 l10n round 1
  l10n: Update Catalan translation
  l10n: de.po: Update German translation for Git v2.32.0
  l10n: README: note on fuzzy translations
  l10n: README: document l10n conventions
  l10n: README: document "core translation"
  l10n: README: document git-po-helper
  l10n: README: add file extention ".md"
  l10n: pt_PT: add Portuguese translations part 3
  l10n: bg.po: Updated Bulgarian translation (5204t)
  l10n: id: po-id for 2.32.0 (round 1)
  l10n: vi.po(5204t): Updated Vietnamese translation for v2.32.0
  l10n: zh_TW.po: localized
  l10n: zh_TW.po: v2.32.0 round 1 (11 untranslated)
  l10n: sv.po: Update Swedish translation (5204t0f0u)
  l10n: fix typos in po/TEAMS
  l10n: fr: v2.32.0 round 1
  l10n: tr: v2.32.0-r1
  l10n: fr: fixed inconsistencies
  ...

Merge branch 'rs/parallel-checkout-test-fix'

Test fix.

* rs/parallel-checkout-test-fix:
  parallel-checkout: avoid dash local bug in tests

Merge branch 'jc/fsync-can-fail-with-eintr'

Last minute portability fix.

* jc/fsync-can-fail-with-eintr:
  fsync(): be prepared to see EINTR

parallel-checkout: avoid dash local bug in tests

Dash bug https://bugs.launchpad.net/ubuntu/+source/dash/+bug/139097
lets the shell erroneously perform field splitting on the expansion of a
command substitution during declaration of a local variable.  It causes
the parallel-checkout tests to fail e.g. when running them with
/bin/dash on MacOS 11.4, where they error out like this:

   ./t2080-parallel-checkout-basics.sh: 33: local: 0: bad variable name

That's because the output of wc -l contains leading spaces and the
returned number of lines is treated as another variable to declare, i.e.
as in "local workers= 0".

Work around it by enclosing the command substitution in quotes.

Helped-by: Matheus Tavares Bernardino <matheus.bernardino@usp.br>
Helped-by: SZEDER Gábor <szeder.dev@gmail.com>
Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: es: 2.32.0 round 1

Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com>

l10n: zh_CN: for git v2.32.0 l10n round 1

Translate 126 new messages (5204t0f0u) for git 2.32.0.

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

Merge branch 'fix_typo' of github.com:e-yes/git

* 'fix_typo' of github.com:e-yes/git:
  l10n: ru.po: fix typo in Russian translation

fsync(): be prepared to see EINTR

Some platforms, like NonStop do not automatically restart fsync()
when interrupted by a signal, even when that signal is setup with
SA_RESTART.

This can lead to test breakage, e.g., where "--progress" is used,
thus SIGALRM is sent often, and can interrupt an fsync() syscall.

Make sure we deal with such a case by retrying the syscall
ourselves.  Luckily, we call fsync() fron a single wrapper,
fsync_or_die(), so the fix is fairly isolated.

Reported-by: Randall S. Becker <randall.becker@nexbridge.ca>
Helped-by: Jeff King <peff@peff.net>
Helped-by: Taylor Blau <me@ttaylorr.com>
[jc: the above two did most of the work---I just tied the loose end]
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

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

* 'pt-PT' of github.com:git-l10n-pt-PT/git-po:
  l10n: pt_PT: add Portuguese translations part 3
  l10n: pt_PT: add Portuguese translations part 2

l10n: Update Catalan translation

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

l10n: de.po: Update German translation for Git v2.32.0

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

Git 2.32-rc3

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

contrib/completion: fix zsh completion regression from 59d85a2a05

A recent change to make git-completion.bash use $__git_cmd_idx
in more places broke a number of completions on zsh because it
modified __git_main but did not update __git_zsh_main.

Notably, completions for "add", "branch", "mv" and "push" were
broken as a result of this change.

In addition to the undefined variable usage, "git mv <tab>" also
prints the following error:

__git_count_arguments:7: bad math expression:
operand expected at `"1"'

_git_mv:[:7: unknown condition: -gt

Remove the quotes around $__git_cmd_idx in __git_count_arguments
and set __git_cmd_idx=1 early in __git_zsh_main to fix the
regressions from 59d85a2a05.

This was tested on zsh 5.7.1 (x86_64-apple-darwin19.0).

Suggested-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
Acked-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: README: note on fuzzy translations

Fuzzy translation problem can occur when updating translations.

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

l10n: README: document l10n conventions

Document the conventions that l10n contributors must follow.

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

l10n: README: document "core translation"

Contributor for a new language must complete translations of a small set
of l10n messages.

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

l10n: README: document git-po-helper

Document the PO helper program (git-po-helper) with installation and
basic usage.

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

l10n: README: add file extention ".md"

Add file extension ".md" to "po/README" to help to display this markdown
file properly.

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

Merge branch 'ab/fsck-api-cleanup'

Last minute compilation fix.

* ab/fsck-api-cleanup:
  builtin/fsck.c: don't conflate "int" and "enum" in callback

builtin/fsck.c: don't conflate "int" and "enum" in callback

Fix a warning on AIX's xlc compiler that's been emitted since my
a1aad71601a (fsck.h: use "enum object_type" instead of "int",
2021-03-28):

    "builtin/fsck.c", line 805.32: 1506-068 (W) Operation between
    types "int(*)(struct object*,enum object_type,void*,struct
    fsck_options*)" and "int(*)(struct object*,int,void*,struct
    fsck_options*)" is not allowed.

I.e. it complains about us assigning a function with a prototype "int"
where we're expecting "enum object_type".

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: pt_PT: add Portuguese translations part 3

* Correct malformed strings
* Transforming 'não' (no) into affirmative

Signed-off-by: Daniel Santos <hello@brighterdan.com>

Merge branch 'l10n/zh_TW/21-05-20' of github.com:l10n-tw/git-po

* 'l10n/zh_TW/21-05-20' of github.com:l10n-tw/git-po:
  l10n: zh_TW.po: localized
  l10n: zh_TW.po: v2.32.0 round 1 (11 untranslated)

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

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

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

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

Git 2.32-rc2

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

Merge branch 'en/dir-traversal'

Fix-up to a topic that is already in 'master'.

* en/dir-traversal:
  dir: introduce readdir_skip_dot_and_dotdot() helper
  dir: update stale description of treat_directory()
  Revert "dir: update stale description of treat_directory()"
  Revert "dir: introduce readdir_skip_dot_and_dotdot() helper"

dir: introduce readdir_skip_dot_and_dotdot() helper

Many places in the code were doing
    while ((d = readdir(dir)) != NULL) {
        if (is_dot_or_dotdot(d->d_name))
            continue;
        ...process d...
    }
Introduce a readdir_skip_dot_and_dotdot() helper to make that a one-liner:
    while ((d = readdir_skip_dot_and_dotdot(dir)) != NULL) {
        ...process d...
    }

This helper particularly simplifies checks for empty directories.

Also use this helper in read_cached_dir() so that our statistics are
consistent across platforms.  (In other words, read_cached_dir() should
have been using is_dot_or_dotdot() and skipping such entries, but did
not and left it to treat_path() to detect and mark such entries as
path_none.)

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

dir: update stale description of treat_directory()

The documentation comment for treat_directory() was originally written
in 095952 (Teach directory traversal about subprojects, 2007-04-11)
which was before the 'struct dir_struct' split its bitfield of named
options into a 'flags' enum in 7c4c97c0 (Turn the flags in struct
dir_struct into a single variable, 2009-02-16). When those flags
changed, the comment became stale, since members like
'show_other_directories' transitioned into flags like
DIR_SHOW_OTHER_DIRECTORIES.

Update the comments for treat_directory() to use these flag names rather
than the old member names.

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

Revert "dir: update stale description of treat_directory()"

This reverts commit 4e689d81718eb6e939cace317ea3e33cb994dcbb,
to be replaced with a reworked version.

Revert "dir: introduce readdir_skip_dot_and_dotdot() helper"

This reverts commit b548f0f1568f6b01e55ca69c24d3cb19489f92aa,
to be replaced with a reworked version.

Merge branch 'ab/pack-linkage-fix'

"ld" on Solaris fails to link some test helpers, which has been
worked around by reshuffling the inline function definitions from a
header file to a source file that is the only user of them.

* ab/pack-linkage-fix:
  pack-objects: move static inline from a header to the sole consumer

Merge branch 'mt/t2080-cp-symlink-fix'

Test portability fix.

* mt/t2080-cp-symlink-fix:
  t2080: fix cp invocation to copy symlinks instead of following them

Merge branch 'ab/send-email-inline-hooks-path'

Code simplification.

* ab/send-email-inline-hooks-path:
  send-email: move "hooks_path" invocation to git-send-email.perl
  send-email: don't needlessly abs_path() the core.hooksPath

Merge branch 'ds/t1092-fix-flake-from-progress'

Workaround flaky tests introduced recently.

* ds/t1092-fix-flake-from-progress:
  t1092: revert the "-1" hack for emulating "no progress meter"
  t1092: use GIT_PROGRESS_DELAY for consistent results

pack-objects: move static inline from a header to the sole consumer

Move the code that is only used in builtin/pack-objects.c out of
pack-objects.h.

This fixes an issue where Solaris's SunCC hasn't been able to compile
git since 483fa7f42d9 (t/helper/test-bitmap.c: initial commit,
2021-03-31).

The real origin of that issue is that in 898eba5e630 (pack-objects:
refer to delta objects by index instead of pointer, 2018-04-14)
utility functions only needed by builtin/pack-objects.c were added to
pack-objects.h. Since then the header has been used in a few other
places, but 483fa7f42d9 was the first time it was used by test helper.

Since Solaris is stricter about linking and the oe_get_size_slow()
function lives in builtin/pack-objects.c the build started failing
with:

    Undefined                       first referenced
     symbol                             in file
    oe_get_size_slow                    t/helper/test-bitmap.o
    ld: fatal: symbol referencing errors. No output written to t/helper/test-tool

On other platforms this is presumably OK because the compiler and/or
linker detects that the "static inline" functions that reference
oe_get_size_slow() aren't used.

Let's solve this by moving the relevant code from pack-objects.h to
builtin/pack-objects.c. This is almost entirely a code-only move, but
because of the early macro definitions in that file referencing some
of these inline functions we need to move the definition of "static
struct packing_data to_pack" earlier, and declare these inline
functions above the macros.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'fr_next' of github.com:jnavila/git

* 'fr_next' of github.com:jnavila/git:
  l10n: fr: v2.32.0 round 1
  l10n: fr: fixed inconsistencies
  l10n: fr.po fixed inconsistencies

t2080: fix cp invocation to copy symlinks instead of following them

t2080 makes a few copies of a test repository and later performs a
branch switch on each one of the copies to verify that parallel checkout
and sequential checkout produce the same results. However, the
repository is copied with `cp -R` which, on some systems, defaults to
following symlinks on the directory hierarchy and copying their target
files instead of copying the symlinks themselves. AIX is one example of
system where this happens. Because the symlinks are not preserved, the
copied repositories have paths that do not match what is in the index,
causing git to abort the checkout operation that we want to test. This
makes the test fail on these systems.

Fix this by copying the repository with the POSIX flag '-P', which
forces cp to copy the symlinks instead of following them. Note that we
already use this flag for other cp invocations in our test suite (see
t7001). With this change, t2080 now passes on AIX.

Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-email: move "hooks_path" invocation to git-send-email.perl

Move the newly added "hooks_path" API in Git.pm to its only user in
git-send-email.perl. This was added in c8243933c74 (git-send-email:
Respect core.hooksPath setting, 2021-03-23), meaning that it hasn't
yet made it into a non-rc release of git.

The consensus with Git.pm is that we need to be considerate of
out-of-tree users who treat it as a public documented interface. We
should therefore be less willing to add new functionality to it, least
we be stuck supporting it after our own uses for it disappear.

In this case the git-send-email.perl hook invocation will probably be
replaced by a future "git hook run" command, and in the commit
preceding this one the "hooks_path" become nothing but a trivial
wrapper for "rev-parse --git-path hooks" anyway (with no
Cwd::abs_path() call), so let's just inline this command in
git-send-email.perl itself.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-email: don't needlessly abs_path() the core.hooksPath

In c8243933c74 (git-send-email: Respect core.hooksPath setting,
2021-03-23) we started supporting core.hooksPath in "send-email". It's
been reported that on Windows[1] doing this by calling abs_path()
results in different canonicalizations of the absolute path.

This wasn't an issue in c8243933c74 itself, but was revealed by my
ea7811b37e0 (git-send-email: improve --validate error output,
2021-04-06) when we started emitting the path to the hook, which was
previously only internal to git-send-email.perl.

The just-landed 53753a37d09 (t9001-send-email.sh: fix expected
absolute paths on Windows, 2021-05-24) narrowly fixed this issue, but
I believe we can do better here. We should not be relying on whatever
changes Perl's abs_path() makes to the path "rev-parse --git-path
hooks" hands to us. Let's instead trust it, and hand it to Perl's
system() in git-send-email.perl. It will handle either a relative or
absolute path.

So let's revert most of 53753a37d09 and just have "hooks_path" return
what we get from "rev-parse" directly without modification. This has
the added benefit of making the error message friendlier in the common
case, we'll no longer print an absolute path for repository-local hook
errors.

1. http://lore.kernel.org/git/bb30fe2b-cd75-4782-24a6-08bb002a0367@kdbg.org

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1092: revert the "-1" hack for emulating "no progress meter"

This looked like a good idea, but it seems to break tests on 32-bit
builds rather badly.  Revert to just use "100 thousands must be big
enough" for now.

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

l10n: id: po-id for 2.32.0 (round 1)

Translate following components:

  * builtin/add.c
  * worktree.c
  * builtin/branch.c
  * builtin/commit.c
  * builtin/merge.c
  * builtin/rebase.c
  * builtin/pull.c
  * diff.c
  * add-interactive.c
  * builtin/log.c
  * builtin/stash.c
  * builtin/tag.c
  * config.c
  * builtin/config.c
  * reset.c
  * builtin/remote.c
  * builtin/rm.c
  * builtin/mv.c
  * builtin/clean.c
  * builtin/help.c
  * archive.c
  * submodule.c
  * builtin/submodule--helper.c
  * submodule-config.c

Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>

Merge branch 'mt/init-template-userpath-fix'

Regression fix.

* mt/init-template-userpath-fix:
  init: fix bug regarding ~/ expansion in init.templateDir

Merge branch 'jt/send-email-validate-errors-fix'

Fix a test breakage.

* jt/send-email-validate-errors-fix:
  t9001-send-email.sh: fix expected absolute paths on Windows

Merge branch 'ab/send-email-validate-errors-fix'

* ab/send-email-validate-errors-fix:
  send-email: fix missing error message regression

t1092: use GIT_PROGRESS_DELAY for consistent results

The t1092-sparse-checkout-compatibility.sh tests compare the stdout and
stderr for several Git commands across both full checkouts, sparse
checkouts with a full index, and sparse checkouts with a sparse index.
Since these are direct comparisons, sometimes a progress indicator can
flush at unpredictable points, especially on slower machines. This
causes the tests to be flaky.

One standard way to avoid this is to add GIT_PROGRESS_DELAY=0 to the Git
commands that are run, as this will force every progress indicator
created with start_progress_delay() to be created immediately. However,
there are some progress indicators that are created in the case of a
full index that are not created with a sparse index. Moreover, their
values may be different as those indexes have a different number of
entries.

Instead, use GIT_PROGRESS_DELAY=-1 (which will turn into UINT_MAX)
to ensure that any reasonable machine running these tests would
never display delayed progress indicators.

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

init: fix bug regarding ~/ expansion in init.templateDir

We used to read the init.templateDir setting at builtin/init-db.c using
a git_config() callback that, in turn, called git_config_pathname(). To
simplify the config reading logic at this file and plug a memory leak,
this was replaced by a direct call to git_config_get_value() at
e4de4502e6 ("init: remove git_init_db_config() while fixing leaks",
2021-03-14). However, this function doesn't provide path expanding
semantics, like git_config_pathname() does, so paths with '~/' and
'~user/' are treated literally. This makes 'git init' fail to handle
init.templateDir paths using these constructs:

$ git config init.templateDir '~/templates_dir'
$ git init
'warning: templates not found in ~/templates_dir'

Replace the git_config_get_value() call by git_config_get_pathname(),
which does the '~/' and '~user/' expansions. Also add a regression test.
Note that unlike git_config_get_value(), the config cache does not own
the memory for the path returned by git_config_get_pathname(), so we
must free() it.

Reported on IRC by rkta.

Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-email: fix missing error message regression

Fix a regression with the "the editor exited uncleanly, aborting
everything" error message going missing after my
d21616c0394 (git-send-email: refactor duplicate $? checks into a
function, 2021-04-06).

I introduced a $msg variable, but did not actually use it. This caused
us to miss the optional error message supplied by the "do_edit"
codepath. Fix that, and add tests to check that this works.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9001-send-email.sh: fix expected absolute paths on Windows

Git for Windows is a native Windows program that works with native
absolute paths in the drive letter style C:\dir. The auxiliary
infrastructure is based on MSYS2, which uses POSIX style /C/dir.

When we test for output of absolute paths produced by git.exe, we
usally have to expect C:\dir style paths. To produce such expected
paths, we have to use $(pwd) in the test scripts; the alternative,
$PWD, produces a POSIX style path. ($PWD is a shell variable, and the
shell is bash, an MSYS2 program, and operates in the POSIX realm.)

There are two recently added tests that were written to expect C:\dir
paths. The output that is tested is produced by `git send-email`, but
behind the scenes, this is a Perl script, which also works in the
POSIX realm and produces /C/dir style output.

In the first test case that is changed here, replace $(pwd) by $PWD
so that the expected path is constructed using /C/dir style.

The second test case sets core.hooksPath to an absolute path. Since
the test script talks to native git.exe, it is supposed to place a
C:/dir style path into the configuration; therefore, keep $(pwd).
When this configuration value is consumed by the Perl script, it is
transformed to /C/dir style by the MSYS2 layer and echoed back in
this form in the error message. Hence, do use $PWD for the expected
value.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

packfile-uri.txt: fix blobPackfileUri description

Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt
and the correct format also can be seen in t5702.

Signed-off-by: Teng Long <dyroneteng@gmail.com>
Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: vi.po(5204t): Updated Vietnamese translation for v2.32.0

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

l10n: zh_TW.po: localized

Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>

Git 2.32-rc1

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

Merge branch 'dl/stash-show-untracked-fixup'

Another brown paper bag inconsistency fix for a new feature
introduced during this cycle.

* dl/stash-show-untracked-fixup:
  stash show: use stash.showIncludeUntracked even when diff options given

Merge branch 'jh/simple-ipc-sans-pthread'

The "simple-ipc" did not compile without pthreads support, but the
build procedure was not properly account for it.

* jh/simple-ipc-sans-pthread:
  simple-ipc: correct ifdefs when NO_PTHREADS is defined

Merge branch 'wm/rev-parse-path-format-wo-arg'

The "rev-parse" command did not diagnose the lack of argument to
"--path-format" option, which was introduced in v2.31 era, which
has been corrected.

* wm/rev-parse-path-format-wo-arg:
  rev-parse: fix segfault with missing --path-format argument

stash show: use stash.showIncludeUntracked even when diff options given

If options pertaining to how the diff is displayed is provided to
`git stash show`, the command will ignore the stash.showIncludeUntracked
configuration variable, defaulting to not showing any untracked files.
This is unintuitive behaviour since the format of the diff output and
whether or not to display untracked files are orthogonal.

Use stash.showIncludeUntracked even when diff options are given. Of
course, this is still overridable via the command-line options.

Update the documentation to explicitly say which configuration variables
will be overridden when a diff options are given.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: zh_TW.po: v2.32.0 round 1 (11 untranslated)

Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>

simple-ipc: correct ifdefs when NO_PTHREADS is defined

Simple IPC always requires threads (in addition to various
platform-specific IPC support).  Fix the ifdefs in the Makefile
to define SUPPORTS_SIMPLE_IPC when appropriate.

Previously, the Unix version of the code would only verify that
Unix domain sockets were available.

This problem was reported here:
https://lore.kernel.org/git/YKN5lXs4AoK%2FJFTO@coredump.intra.peff.net/T/#m08be8f1942ea8a2c36cfee0e51cdf06489fdeafc

Reported-by: Randall S. Becker <rsbecker@nexbridge.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'ds/sparse-index-protections'

Fix access to uninitialized piece of memory, introduced during this
cycle.

* ds/sparse-index-protections:
  sparse-index: fix uninitialized jump

Merge branch 'tz/c-locale-output-is-no-more'

Test update.

* tz/c-locale-output-is-no-more:
  t7500: remove non-existant C_LOCALE_OUTPUT prereq

Merge branch 'cs/http-use-basic-after-failed-negotiate'

Regression fix for a change made during this cycle.

* cs/http-use-basic-after-failed-negotiate:
  Revert "remote-curl: fall back to basic auth if Negotiate fails"
  t5551: test http interaction with credential helpers

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

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

merge-ort, diffcore-rename: employ cached renames when possible

When there are many renames between the old base of a series of commits
and the new base, the way sequencer.c, merge-recursive.c, and
diffcore-rename.c have traditionally split the work resulted in
redetecting the same renames with each and every commit being
transplanted.  To address this, the last several commits have been
creating a cache of rename detection results, determining when it was
safe to use such a cache in subsequent merge operations, adding helper
functions, and so on.  See the previous half dozen commit messages for
additional discussion of this optimization, particularly the message a
few commits ago entitled "add code to check for whether cached renames
can be reused".  This commit finally ties all of that work together,
modifying the merge algorithm to make use of these cached renames.

For the testcases mentioned in commit 557ac0350d ("merge-ort: begin
performance work; instrument with trace2_region_* calls", 2020-10-28),
this change improves the performance as follows:

                            Before                  After
    no-renames:        5.665 s ±  0.129 s     5.622 s ±  0.059 s
    mega-renames:     11.435 s ±  0.158 s    10.127 s ±  0.073 s
    just-one-mega:   494.2  ms ±  6.1  ms   500.3  ms ±  3.8  ms

That's a fairly small improvement, but mostly because the previous
optimizations were so effective for these particular testcases; this
optimization only kicks in when the others don't.  If we undid the
basename-guided rename detection and skip-irrelevant-renames
optimizations, then we'd see that this series by itself improved
performance as follows:

                   Before Basename Series   After Just This Series
    no-renames:      13.815 s ±  0.062 s      5.697 s ±  0.080 s
    mega-renames:  1799.937 s ±  0.493 s    205.709 s ±  0.457 s

Since this optimization kicks in to help accelerate cases where the
previous optimizations do not apply, this last comparison shows that
this cached-renames optimization has the potential to help signficantly
in cases that don't meet the requirements for the other optimizations to
be effective.

The changes made in this optimization also lay some important groundwork
for a future optimization around having collect_merge_info() avoid
recursing into subtrees in more cases.

However, for this optimization to be effective, merge_switch_to_result()
should only be called when the rebase or cherry-pick operation has
either completed or hit a case where the user needs to resolve a
conflict or edit the result.  If it is called after every commit, as
sequencer.c does, then the working tree and index are needlessly updated
with every commit and the cached metadata is tossed, defeating this
optimization.  Refactoring sequencer.c to only call
merge_switch_to_result() at the end of the operation is a bigger
undertaking, and the practical benefits of this optimization will not be
realized until that work is performed.  Since `test-tool fast-rebase`
only updates at the end of the operation, it was used to obtain the
timings above.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-ort: handle interactions of caching and rename/rename(1to1) cases

As documented in Documentation/technical/remembering-renames.txt, and as
tested for in the two testcases in t6429 with "rename same file
identically" in their description, there is one case where we need to
have renames in one commit NOT be cached for the next commit in our
rebase sequence -- namely, rename/rename(1to1) cases.  Rather than
specifically trying to uncache those and fix up dir_rename_counts() to
match (which would also be valid but more work), we simply disable the
optimization when this really rare type of rename occurs.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-ort: add helper functions for using cached renames

If we have a usable rename cache, then we can remove from
relevant_sources all the paths that were cached;
diffcore_rename_extended() can then consider an even smaller set of
relevant_sources in its rename detection.

However, when diffcore_rename_extended() is done, we will need to take
the renames it detected and then add back in all the ones we had cached
from before.

Add helper functions for doing these two operations; the next commit
will make use of them.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-ort: preserve cached renames for the appropriate side

Previous commits created an in-memory cache of the results of rename
detection, and added logic to detect when that cache could appropriately
be used in a subsequent merge operation -- but we were still
unconditionally clearing the cache with each new merge operation anyway.
If it is valid to reuse the cache from one of the two sides of history,
preserve that side.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-ort: avoid accidental API mis-use

Previously, callers of the merge-ort API could have passed an
uninitialized value for struct merge_result *result.  However, we want
to check result to see if it has cached renames from a previous merge
that we can reuse; such values would be found behind result->priv.
However, if result->priv is uninitialized, attempting to access behind
it will give a segfault.  So, we need result->priv to be NULL (which
will be the case if the caller does a memset(&result, 0)), or be written
by a previous call to the merge-ort machinery.  Documenting this
requirement may help, but despite being the person who introduced this
requirement, I still missed it once and it did not fail in a very clear
way and led to a long debugging session.

Add a _properly_initialized field to merge_result; that value will be
0 if the caller zero'ed the merge_result, it will be set to a very
specific value by a previous run by the merge-ort machinery, and if it's
uninitialized it will most likely either be 0 or some value that does
not match the specific one we'd expect allowing us to throw a much more
meaningful error.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-ort: add code to check for whether cached renames can be reused

We need to know when renames detected in a previous merge operation can
be reused in a later merge operation.  Consider the following setup
(from the git-rebase manpage):

                     A---B---C topic
                    /
               D---E---F---G master

After rebasing, this will appear as:

                             A'--B'--C' topic
                            /
               D---E---F---G master

Further, let's say that 'oldfile' was renamed to 'newfile' between E
and G.  The rebase or cherry-pick of A onto G will involve a three-way
merge between E (as the merge base) and G and A.  After detecting the
rename between E:oldfile and G:newfile, there will be a three-way
content merge of the following:
    E:oldfile
    G:newfile
    A:oldfile
and produce a new result:
    A':newfile

Now, when we want to pick B onto A', we will need to do a three-way
merge between A (as the merge-base) and A' and B.  This will involve
a three-way content merge of
    A:oldfile
    A':newfile
    B:oldfile
but only if we can detect that A:oldfile is similar enough to A':newfile
to be used together in a three-way content merge, i.e. only if we can
detect that A:oldfile and A':newfile are a rename.  But we already know
that A:oldfile and A':newfile are similar enough to be used in a
three-way content merge, because that is precisely where A':newfile came
from in the previous merge.

Note that A & A' both appear in both merges.  That gives us the
condition under which we can reuse renames.

There are a couple important points about this optimization:

  - If the rebase or cherry-pick halts for user conflicts, these caches
    are NOT saved anywhere.  Thus, resuming a halted rebase or
    cherry-pick will result in no reused renames for the next commit.
    This is intentional, as user resolution can change files
    significantly and in ways that violate the similarity assumptions
    here.

  - Technically, in a *very* narrow case this might give slightly
    different results for rename detection.  Using the example above,
    if:
      * E:oldfile had 20 lines
      * G:newfile added 10 new lines at the beginning of the file
      * A:oldfile deleted all but the first three lines of the file
    then
      => A':newfile would have 13 lines, 3 of which matches those
         in A:oldfile.

    Consider the two cases:
      * Without this optimization:
        - the next step of the rebase operation (moving B to B')
          would not detect the rename betwen A:oldfile and A':newfile
        - we'd thus get a modify/delete conflict with the rebase
          operation halting for the user to resolve, and have both
          A':newfile and B:oldfile sitting in the working tree.
      * With this optimization:
        - the rename between A:oldfile and A':newfile would be detected
          via the cache of renames
        - a three-way merge between A:oldfile, A':newfile, and B:oldfile
          would commence and be written to A':newfile

    Now, is the difference in behavior a bug...or a bugfix?  I can't
    tell.  Given that A:oldfile and A':newfile are not very similar,
    when we three-way merge with B:oldfile it seems likely we'll hit a
    conflict for the user to resolve.  And it shouldn't be too hard for
    users to see why we did that three-way merge; oldfile and newfile
    *were* renames somewhere in the sequence.  So, most of these corner
    cases will still behave similarly -- namely, a conflict given to the
    user to resolve.  Also, consider the interesting case when commit B
    is a clean revert of commit A.  Without this optimization, a rebase
    could not both apply a weird patch like A and then immediately
    revert it; users would be forced to resolve merge conflicts.  With
    this optimization, it would successfully apply the clean revert.
    So, there is certainly at least one case that behaves better.  Even
    if it's considered a "difference in behavior", I think both behaviors
    are reasonable, and the time savings provided by this optimization
    justify using the slightly altered rename heuristics.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-ort: populate caches of rename detection results

Fill in cache_pairs, cached_target_names, and cached_irrelevant based on
rename detection results.  Future commits will make use of these values.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-ort: add data structures for in-memory caching of rename detection

When there are many renames between the old base of a series of commits
and the new base for a series of commits, the sequence of merges
employed to transplant those commits (from a cherry-pick or rebase
operation) will repeatedly detect the exact same renames.  This is
wasted effort.

Add data structures which will be used to cache rename detection
results, along with the initialization and deallocation of these data
structures.  Future commits will populate these caches, detect the
appropriate circumstances when they can be used, and employ them to
avoid re-detecting the same renames repeatedly.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t6429: testcases for remembering renames

We will soon be adding an optimization that caches (in memory only,
never written to disk) upstream renames during a sequence of merges such
as occurs during a cherry-pick or rebase operation.  Add several tests
meant to stress such an implementation to ensure it does the right
thing, and include a test whose outcome we will later change due to this
optimization as well.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fast-rebase: write conflict state to working tree, index, and HEAD

Previously, when fast-rebase hit a conflict, it simply aborted and left
HEAD, the index, and the working tree where they were before the
operation started.  While fast-rebase does not support restarting from a
conflicted state, write the conflicted state out anyway as it gives us a
way to see what the conflicts are and write tests that check for them.

This will be important in the upcoming commits, because sequencer.c is
only superficially integrated with merge-ort.c; in particular, it calls
merge_switch_to_result() after EACH merge instead of only calling it at
the end of all the sequence of merges (or when a conflict is hit).  This
not only causes needless updates to the working copy and index, but also
causes all intermediate data to be freed and tossed, preventing caching
information from one merge to the next.  However, integrating
sequencer.c more deeply with merge-ort.c is a big task, and making this
small extension to fast-rebase.c provides us with a simple way to test
the edge and corner cases that we want to make sure continue working.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fast-rebase: change assert() to BUG()

assert() can succinctly document expectations for the code, and do so in
a way that may be useful to future folks trying to refactor the code and
change basic assumptions; it allows them to more quickly find some
places where their violations of previous assumptions trips things up.

Unfortunately, assert() can surround a function call with important
side-effects, which is a huge mistake since some users will compile with
assertions disabled.  I've had to debug such mistakes before in other
codebases, so I should know better.  Luckily, this was only in test
code, but it's still very embarrassing.  Change an assert() to an if
(...) BUG (...).

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/technical: describe remembering renames optimization

Remembering renames on the upstream side of history in an early merge of
a rebase or cherry-pick for re-use in a latter merge of the same
operation makes pretty good intuitive sense.  However, trying to show
that it doesn't cause some subtle behavioral difference or some funny
edge or corner case is much more involved.  And, in fact, it does
introduce a subtle behavioral change.

Document all the assumptions, special cases, and logic involved in such
an optimization, and describe why this optimization is safe under the
current optimizations/features/etc. -- even when the subtle behavioral
change is triggered.

Part of the point of adding this document that goes over the
optimization in such laborious detail, is that it is possible that
significant future changes (optimizations or feature changes) could
interact with this optimization in interesting ways; this document is
here to help folks making big changes sanity check that the assumptions
and arguments underlying this optimization are still valid.  (As a side
note, creating this document forced me to review things in sufficient
detail that I found I was not properly caching directory-rename-induced
renames, resulting in the code not being aware of those renames and
causing unnecessary diffcore_rename_extended() calls in subsequent
merges.)

A subsequent commit will add several testcases based on this document
meant to stress-test the implementation and also document the case with
the subtle behavioral change.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: explain the use of color.pager

The current documentation for color.pager is technically correct, but
slightly misleading and doesn't really clarify the purpose of the
variable. As explained in the original thread which added it:

  https://lore.kernel.org/git/E1G6zPH-00062L-Je@moooo.ath.cx/

the point is to deal with pagers that don't understand colors. And hence it
being set to "true" is necessary for colorizing output to the pager, but
not sufficient by itself (you must also have enabled one of the other
color options, though note that these are set to "auto" by default these
days).

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

l10n: fix typos in po/TEAMS

Find typos in "po/TEAMS" file using the "git-po-helper" program.  These
typos were introduced from commit v2.24.0-1-g9917eca794 (l10n: zh_TW:
add translation for v2.24.0, 2019-11-20 19:14:22 +0800).

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

setup: split "extensions found" messages into singular and plural

It's easier to translate this way.

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: improve grammar of "shallow roots" message

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>