config: use size_t to store parsed variable baselen

Most of the config parsing infrastructure is limited in what it can
parse only by the size of memory, because it parses character by
character, building up strbufs for keys, values, etc. One exception is
the "baselen" value we keep in git_parse_source(), which is an int.

That stores the length of the section.subsection base, to which we can
then append individual key names (by truncating back to the baselen with
strbuf_setlen(), and then appending characters for the key name). But
because it's an int, if we see an absurdly long section or subsection,
we may overflow the integer, wrapping negative. That negative value is
then implicitly cast to a size_t when we pass it to strbuf_setlen(),
creating a very large value and triggering a BUG. For example:

  $ {
       printf '[foo "'
       perl -e 'print "a" x 2**31'
       echo '"]bar = value'
    } >huge
  $ git config --file=huge --list
  fatal: BUG: strbuf_setlen() beyond buffer

While this is obviously a silly case that we don't care about
supporting, it's worth fixing it by switching to a size_t for a few
reasons:

  - we should try to avoid hitting BUG assertions at all

  - avoiding integer truncation or overflow sets a good example and
    makes it easier to audit the code for more important issues

  - the BUG outcome is what happens in _this_ instance, because we wrap
    negative. If we used a 2**32 subsection, we'd wrap to a small
    positive value and actually generate wrong output (the subsection of
    our key would be truncated).

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

git_config_parse_key(): return baselen as size_t

As with the recent change to parse_config_key(), the best type to return
a string length is a size_t, as it won't cause integer truncation for a
gigantic key. And as with that change, this is mostly a clarity /
hygiene issue for now, as our config parser would choke on such a large
key anyway.

There are a few ripple effects within the config code, as callers switch
to using size_t. I also adjusted a few related variables that iterate
over strings. The most unexpected change is that a call to strbuf_addf()
had to switch to strbuf_add(). We can't use a size_t with "%.*s",
because printf precisions must have type "int" (we could cast, of
course, but that would miss the point of using size_t in the first
place).

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

config: drop useless length variable in write_pair()

We compute the length of a subset of a string, but then use that length
only to feed a "%.*s" printf placeholder for the same string. We can
just use "%s" to achieve the same thing.

The variable became useless in cb891a5989 (Use a strbuf for building up
section header and key/value pair strings., 2007-12-14), which swapped
out a write() which _did_ use the length for a strbuf_addf() call.

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

parse_config_key(): return subsection len as size_t

We return the length to a subset of a string using an "int *"
out-parameter. This is fine most of the time, as we'd expect config keys
to be relatively short, but it could behave oddly if we had a gigantic
config key. A more appropriate type is size_t.

Let's switch over, which lets our callers use size_t as appropriate
(they are bound by our type because they must pass the out-parameter as
a pointer). This is mostly just a cleanup to make it clear this code
handles long strings correctly. In practice, our config parser already
chokes on long key names (because of a similar int/size_t mixup!).

When doing an int/size_t conversion, we have to be careful that nobody
was trying to assign a negative value to the variable. I manually
confirmed that for each case here. They tend to just feed the result to
xmemdupz() or similar; in a few cases I adjusted the parameter types for
helper functions to make sure the size_t is preserved.

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

remote: drop auto-strlen behavior of make_branch() and make_rewrite()

The make_branch() and make_rewrite() functions can take a NUL-terminated
string or a ptr/len pair. They use a sentinel value of "0" for the len
to tell the difference between the two. However, when parsing config
like:

  [branch ""]
  merge = whatever

whose key flattens to:

  branch..merge

we might actually have a zero-length branch name. This is obviously
nonsense, but the current code would consider it as a NUL-terminated
string and use the branch name ".merge".

We could use a better sentinel value here (like "-1"), but that gets in
the way of moving to size_t, which is a more appropriate type for a
ptr/len combo.

Let's instead just drop this feature and have the callers (of which
there are only two total) use strlen() themselves. This simplifies the
code, and lets us move to using size_t.

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

Merge branch 'ds/default-pack-use-sparse-to-true'

The 'pack.useSparse' configuration variable now defaults to 'true',
enabling an optimization that has been experimental since Git 2.21.

* ds/default-pack-use-sparse-to-true:
  pack-objects: flip the use of GIT_TEST_PACK_SPARSE
  config: set pack.useSparse=true by default

The second batch post 2.26 cycle

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

Merge branch 'ah/force-pull-rebase-configuration'

"git pull" learned to warn when no pull.rebase configuration
exists, and neither --[no-]rebase nor --ff-only is given (which
would result a merge).

* ah/force-pull-rebase-configuration:
  pull: warn if the user didn't say whether to rebase or to merge

Merge branch 'tg/retire-scripted-stash'

"git stash" has kept an escape hatch to use the scripted version
for a few releases, which got stale.  It has been removed.

* tg/retire-scripted-stash:
  stash: remove the stash.useBuiltin setting
  stash: get git_stash_config at the top level

Merge branch 'jc/describe-misnamed-annotated-tag'

When "git describe C" finds an annotated tag with tagname A to be
the best name to explain commit C, and the tag is stored in a
"wrong" place in the refs/tags hierarchy, e.g. refs/tags/B, the
command gave a warning message but used A (not B) to describe C.
If C is exactly at the tag, the describe output would be "A", but
"git rev-parse A^0" would not be equal as "git rev-parse C^0".  The
behavior of the command has been changed to use the "long" form
i.e. A-0-gOBJECTNAME, which is correctly interpreted by rev-parse.

* jc/describe-misnamed-annotated-tag:
  describe: force long format for a name based on a mislocated tag

Merge branch 'at/rebase-fork-point-regression-fix'

The "--fork-point" mode of "git rebase" regressed when the command
was rewritten in C back in 2.20 era, which has been corrected.

* at/rebase-fork-point-regression-fix:
  rebase: --fork-point regression fix

Merge branch 'bc/filter-process'

Provide more information (e.g. the object of the tree-ish in which
the blob being converted appears, in addition to its path, which
has already been given) to smudge/clean conversion filters.

* bc/filter-process:
  t0021: test filter metadata for additional cases
  builtin/reset: compute checkout metadata for reset
  builtin/rebase: compute checkout metadata for rebases
  builtin/clone: compute checkout metadata for clones
  builtin/checkout: compute checkout metadata for checkouts
  convert: provide additional metadata to filters
  convert: permit passing additional metadata to filter processes
  builtin/checkout: pass branch info down to checkout_worktree

Merge branch 'hi/gpg-prefer-check-signature'

The code to interface with GnuPG has been refactored.

* hi/gpg-prefer-check-signature:
  gpg-interface: prefer check_signature() for GPG verification
  t: increase test coverage of signature verification output

Merge branch 'bc/sha-256-part-1-of-4'

SHA-256 transition continues.

* bc/sha-256-part-1-of-4: (22 commits)
  fast-import: add options for rewriting submodules
  fast-import: add a generic function to iterate over marks
  fast-import: make find_marks work on any mark set
  fast-import: add helper function for inserting mark object entries
  fast-import: permit reading multiple marks files
  commit: use expected signature header for SHA-256
  worktree: allow repository version 1
  init-db: move writing repo version into a function
  builtin/init-db: add environment variable for new repo hash
  builtin/init-db: allow specifying hash algorithm on command line
  setup: allow check_repository_format to read repository format
  t/helper: make repository tests hash independent
  t/helper: initialize repository if necessary
  t/helper/test-dump-split-index: initialize git repository
  t6300: make hash algorithm independent
  t6300: abstract away SHA-1-specific constants
  t: use hash-specific lookup tables to define test constants
  repository: require a build flag to use SHA-256
  hex: add functions to parse hex object IDs in any algorithm
  hex: introduce parsing variants taking hash algorithms
  ...

Merge branch 'pb/recurse-submodules-fix'

Fix "git checkout --recurse-submodules" of a nested submodule
hierarchy.

* pb/recurse-submodules-fix:
  t/lib-submodule-update: add test removing nested submodules
  unpack-trees: check for missing submodule directory in merged_entry
  unpack-trees: remove outdated description for verify_clean_submodule
  t/lib-submodule-update: move a test to the right section
  t/lib-submodule-update: remove outdated test description
  t7112: remove mention of KNOWN_FAILURE_SUBMODULE_RECURSIVE_NESTED

The first batch post 2.26 cycle

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

Merge branch 'ss/submodule-foreach-cb'

Code clean-up.

* ss/submodule-foreach-cb:
  submodule--helper.c: Rename 'cb_foreach' to 'foreach_cb'

Merge branch 'jc/config-tar'

Improve the structure of the documentation source a bit.

* jc/config-tar:
  separate tar.* config to its own source file

Merge branch 'en/oidset-uninclude-hashmap'

Code clean-up.

* en/oidset-uninclude-hashmap:
  oidset: remove unnecessary include

Merge branch 'ds/check-connected-reprepare-packed-git'

Corner case "git fetch" fix.

* ds/check-connected-reprepare-packed-git:
  connected.c: reprepare packs for corner cases

Merge branch 'rs/doc-passthru-fetch-options'

Doc update.

* rs/doc-passthru-fetch-options:
  pull: document more passthru options

Merge branch 'pw/advise-rebase-skip'

The mechanism to prevent "git commit" from making an empty commit
or amending during an interrupted cherry-pick was broken during the
rewrite of "git rebase" in C, which has been corrected.

* pw/advise-rebase-skip:
  commit: give correct advice for empty commit during a rebase
  commit: encapsulate determine_whence() for sequencer
  commit: use enum value for multiple cherry-picks
  sequencer: write CHERRY_PICK_HEAD for reword and edit
  cherry-pick: check commit error messages
  cherry-pick: add test for `--skip` advice in `git commit`
  t3404: use test_cmp_rev

Merge branch 'yz/p4-py3'

Update "git p4" to work with Python 3.

* yz/p4-py3:
  ci: use python3 in linux-gcc and osx-gcc and python2 elsewhere
  git-p4: use python3's input() everywhere
  git-p4: simplify regex pattern generation for parsing diff-tree
  git-p4: use dict.items() iteration for python3 compatibility
  git-p4: use functools.reduce instead of reduce
  git-p4: fix freezing while waiting for fast-import progress
  git-p4: use marshal format version 2 when sending to p4
  git-p4: open .gitp4-usercache.txt in text mode
  git-p4: convert path to unicode before processing them
  git-p4: encode/decode communication with git for python3
  git-p4: encode/decode communication with p4 for python3
  git-p4: remove string type aliasing
  git-p4: change the expansion test from basestring to list
  git-p4: make python2.7 the oldest supported version

Merge branch 'am/real-path-fix'

The real_path() convenience function can easily be misused; with a
bit of code refactoring in the callers' side, its use has been
eliminated.

* am/real-path-fix:
  get_superproject_working_tree(): return strbuf
  real_path_if_valid(): remove unsafe API
  real_path: remove unsafe API
  set_git_dir: fix crash when used with real_path()

Merge branch 'sg/commit-slab-clarify-peek'

In-code comment update.

* sg/commit-slab-clarify-peek:
  commit-slab: clarify slabname##_peek()'s return value

Merge branch 'jc/maintain-doc'

Doc update.

* jc/maintain-doc:
  update how-to-maintain-git

Merge branch 'js/https-proxy-config'

A handful of options to configure SSL when talking to proxies have
been added.

* js/https-proxy-config:
  http: add environment variable support for HTTPS proxies
  http: add client cert support for HTTPS proxies

Merge branch 'hw/advise-ng'

Revamping of the advise API to allow more systematic enumeration of
advice knobs in the future.

* hw/advise-ng:
  tag: use new advice API to check visibility
  advice: revamp advise API
  advice: change "setupStreamFailure" to "setUpstreamFailure"
  advice: extract vadvise() from advise()

Git 2.26

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

Merge branch 'en/rebase-backend'

Test fix.

* en/rebase-backend:
  t3419: prevent failure when run with EXPENSIVE

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

l10n-2.26.0-rnd2.1

* tag 'l10n-2.26.0-rnd2.1' of https://github.com/git-l10n/git-po: (28 commits)
  l10n: tr.po: change file mode to 644
  l10n: de.po: Update German translation for Git 2.26.0
  l10n: de.po: add missing space
  l10n: tr: Fix a couple of ambiguities
  l10n: Update Catalan translation
  l10n: sv.po: Update Swedish translation (4839t0f0u)
  l10n: zh_CN: Revise v2.26.0 translation
  l10n: zh_CN: for git v2.26.0 l10n round 1 and 2
  l10n: vi(4839t): Updated Vietnamese translation for v2.26.0
  l10n: vi: fix translation + grammar
  l10n: zh_TW.po: v2.26.0 round 2 (0 untranslated)
  l10n: zh_TW.po: v2.26.0 round 1 (11 untranslated)
  l10n: it.po: update the Italian translation for Git 2.26.0 round 2
  l10n: es: 2.26.0 round#2
  l10n: bg.po: Updated Bulgarian translation (4839t)
  l10n: tr: v2.26.0 round 2
  l10n: fr : v2.26.0 rnd 2
  l10n: git.pot: v2.26.0 round 2 (7 new, 2 removed)
  l10n: tr: Add glossary for Turkish translations
  l10n: sv.po: Update Swedish translation (4835t0f0u)
  ...

l10n: tr.po: change file mode to 644

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

t3419: prevent failure when run with EXPENSIVE

This test runs a function which itself runs several assertions.  The
last of these assertions cleans up the .git/rebase-apply directory,
since when run with EXPENSIVE set, the function is invoked a second time
to run the same tests with a larger data set.

However, as of 2ac0d6273f ("rebase: change the default backend from "am"
to "merge"", 2020-02-15), the default backend of rebase has changed, and
cleaning up the rebase-apply directory has no effect: it no longer
exists, since we're using rebase-merge instead.

Since we don't really care which rebase backend is in use, let's just
use the command "git rebase --quit", which will do the right thing
regardless.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pack-objects: flip the use of GIT_TEST_PACK_SPARSE

The environment variable GIT_TEST_PACK_SPARSE was previously used
to allow testing the --sparse option for "git pack-objects" in
the test suite. This allowed interesting cases of "git push" to
also test this algorithm.

Since pack.useSparse is now true by default, we do not need this
variable to _enable_ the --sparse option, but instead to _disable_
it. This flips how we work with the variable a bit.

When checking for the variable, default to a value of -1 for
"unset". If unset, then take the default from the repo settings,
which is currently 1. Then, the --[no-]sparse command-line option
will override either of these settings.

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

config: set pack.useSparse=true by default

The pack.useSparse config option was introduced by 3d036eb0
(pack-objects: create pack.useSparse setting, 2019-01-19) and was
first available in v2.21.0. When enabled, the pack-objects process
during 'git push' will use a sparse tree walk when deciding which
trees and blobs to send to the remote. The algorithm was introduced
by d5d2e93 (revision: implement sparse algorithm, 2019-01-16) and
has been in production use by VFS for Git since around that time.
The features.experimental config option also enabled pack.useSparse,
so hopefully that has also increased exposure.

It is worth noting that pack.useSparse has a possibility of
sending more objects across a push, but requires a special
arrangement of exact _copies_ across directories. There is a test
in t5322-pack-objects-sparse.sh that demonstrates this possibility.
This test uses the --sparse option to "git pack-objects" but we
can make it implied by the config value to demonstrate that the
default value has changed.

While updating that test, I noticed that the documentation did not
include an option for --no-sparse, which is now more important than
it was before.

Since the downside is unlikely but the upside is significant, set
the default value of pack.useSparse to true. Remove it from the
set of options implied by features.experimental.

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

l10n: de.po: Update German translation for Git 2.26.0

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>

l10n: de.po: add missing space

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>

Merge https://github.com/prati0100/git-gui

* 'master' of https://github.com/prati0100/git-gui:
  git-gui: create a new namespace for chord script evaluation
  git-gui: reduce Tcl version requirement from 8.6 to 8.5
  git-gui--askpass: coerce answers to UTF-8 on Windows
  git-gui: fix error popup when doing blame -> "Show History Context"
  git-gui: add missing close bracket
  git-gui: update German translation
  git-gui: extend translation glossary template with more terms
  git-gui: update pot template and German translation to current source code

l10n: tr: Fix a couple of ambiguities

Signed-off-by: Emir Sarı <bitigchi@me.com>

Merge branch 'py/remove-tcloo'

Reduce the Tcl version requirement to 8.5 to allow git-gui to run on
MacOS distributions like High Sierra. While here, fix a potential
variable name collision.

* py/remove-tcloo:
  git-gui: create a new namespace for chord script evaluation
  git-gui: reduce Tcl version requirement from 8.6 to 8.5

RelNotes/2.26.0: fix various typos

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

submodule--helper.c: Rename 'cb_foreach' to 'foreach_cb'

In 'submodule--helper.c', the structures and macros for callbacks belonging
to any subcommand are named in the format: 'subcommand_cb' and 'SUBCOMMAND_CB_INIT'
respectively.

This was an exception for the subcommand 'foreach' of the command
'submodule'. Rename the aforementioned structures and macros:
'struct cb_foreach' to 'struct foreach_cb' and 'CB_FOREACH_INIT'
to 'FOREACH_CB_INIT'.

Signed-off-by: Shourya Shukla <shouryashukla.oo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

separate tar.* config to its own source file

Even though there is only one configuration variable in the
namespace, it is not quite right to have tar.umask described
among the variables for tag.* namespace.

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

l10n: Update Catalan translation

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

Sync with Git 2.25.2

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

Git 2.25.2

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

unicode: update the width tables to Unicode 13.0

Now that Unicode 13.0 has been announced[0], update the character
width tables to the new version.

[0] https://home.unicode.org/announcing-the-unicode-standard-version-13-0/

Signed-off-by: Beat Bolli <dev+git@drbeat.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'js/ci-windows-update' into maint

Updates to the CI settings.

* js/ci-windows-update:
  Azure Pipeline: switch to the latest agent pools
  ci: prevent `perforce` from being quarantined
  t/lib-httpd: avoid using macOS' sed

Merge branch 'jk/run-command-formatfix' into maint

Code style cleanup.

* jk/run-command-formatfix:
  run-command.h: fix mis-indented struct member

Merge branch 'jk/doc-credential-helper' into maint

Docfix.

* jk/doc-credential-helper:
  doc: move credential helper info into gitcredentials(7)

Merge branch 'js/mingw-open-in-gdb' into maint

Dev support.

* js/mingw-open-in-gdb:
  mingw: add a helper function to attach GDB to the current process

Merge branch 'js/test-unc-fetch' into maint

Test updates.

* js/test-unc-fetch:
  t5580: test cloning without file://, test fetching via UNC paths

Merge branch 'js/test-write-junit-xml-fix' into maint

Testfix.

* js/test-write-junit-xml-fix:
  tests: fix --write-junit-xml with subshells

Merge branch 'en/simplify-check-updates-in-unpack-trees' into maint

Code simplification.

* en/simplify-check-updates-in-unpack-trees:
  unpack-trees: exit check_updates() early if updates are not wanted

Merge branch 'jc/doc-single-h-is-for-help' into maint

Both "git ls-remote -h" and "git grep -h" give short usage help,
like any other Git subcommand, but it is not unreasonable to expect
that the former would behave the same as "git ls-remote --head"
(there is no other sensible behaviour for the latter).  The
documentation has been updated in an attempt to clarify this.

* jc/doc-single-h-is-for-help:
  Documentation: clarify that `-h` alone stands for `help`

Merge branch 'hd/show-one-mergetag-fix' into maint

"git show" and others gave an object name in raw format in its
error output, which has been corrected to give it in hex.

* hd/show-one-mergetag-fix:
  show_one_mergetag: print non-parent in hex form.

Merge branch 'am/mingw-poll-fix' into maint

MinGW's poll() emulation has been improved.

* am/mingw-poll-fix:
  mingw: workaround for hangs when sending STDIN

Merge branch 'hi/gpg-use-check-signature' into maint

"git merge signed-tag" while lacking the public key started to say
"No signature", which was utterly wrong.  This regression has been
reverted.

* hi/gpg-use-check-signature:
  Revert "gpg-interface: prefer check_signature() for GPG verification"

Merge branch 'ds/partial-clone-fixes' into maint

Fix for a bug revealed by a recent change to make the protocol v2
the default.

* ds/partial-clone-fixes:
  partial-clone: avoid fetching when looking for objects
  partial-clone: demonstrate bugs in partial fetch

Merge branch 'en/t3433-rebase-stat-dirty-failure' into maint

The merge-recursive machinery failed to refresh the cache entry for
a merge result in a couple of places, resulting in an unnecessary
merge failure, which has been fixed.

* en/t3433-rebase-stat-dirty-failure:
  merge-recursive: fix the refresh logic in update_file_flags
  t3433: new rebase testcase documenting a stat-dirty-like failure

Merge branch 'en/check-ignore' into maint

"git check-ignore" did not work when the given path is explicitly
marked as not ignored with a negative entry in the .gitignore file.

* en/check-ignore:
  check-ignore: fix documentation and implementation to match

Merge branch 'jk/push-option-doc-markup-fix' into maint

Doc markup fix.

* jk/push-option-doc-markup-fix:
  doc/config/push: use longer "--" line for preformatted example

Merge branch 'jk/doc-diff-parallel' into maint

Update to doc-diff.

* jk/doc-diff-parallel:
  doc-diff: use single-colon rule in rendering Makefile

Merge branch 'jh/notes-fanout-fix' into maint

The code to automatically shrink the fan-out in the notes tree had
an off-by-one bug, which has been killed.

* jh/notes-fanout-fix:
  notes.c: fix off-by-one error when decreasing notes fanout
  t3305: check notes fanout more carefully and robustly

Merge branch 'jk/index-pack-dupfix' into maint

The index-pack code now diagnoses a bad input packstream that
records the same object twice when it is used as delta base; the
code used to declare a software bug when encountering such an
input, but it is an input error.

* jk/index-pack-dupfix:
  index-pack: downgrade twice-resolved REF_DELTA to die()

Merge branch 'js/rebase-i-with-colliding-hash' into maint

"git rebase -i" identifies existing commits in its todo file with
their abbreviated object name, which could become ambigous as it
goes to create new commits, and has a mechanism to avoid ambiguity
in the main part of its execution.  A few other cases however were
not covered by the protection against ambiguity, which has been
corrected.

* js/rebase-i-with-colliding-hash:
  rebase -i: also avoid SHA-1 collisions with missingCommitsCheck
  rebase -i: re-fix short SHA-1 collision
  parse_insn_line(): improve error message when parsing failed

Merge branch 'jk/clang-sanitizer-fixes' into maint

C pedantry ;-) fix.

* jk/clang-sanitizer-fixes:
  obstack: avoid computing offsets from NULL pointer
  xdiff: avoid computing non-zero offset from NULL pointer
  avoid computing zero offsets from NULL pointer
  merge-recursive: use subtraction to flip stage
  merge-recursive: silence -Wxor-used-as-pow warning

Merge branch 'dt/submodule-rm-with-stale-cache' into maint

Running "git rm" on a submodule failed unnecessarily when
.gitmodules is only cache-dirty, which has been corrected.

* dt/submodule-rm-with-stale-cache:
  git rm submodule: succeed if .gitmodules index stat info is zero

Merge branch 'pb/recurse-submodule-in-worktree-fix' into maint

The "--recurse-submodules" option of various subcommands did not
work well when run in an alternate worktree, which has been
corrected.

* pb/recurse-submodule-in-worktree-fix:
  submodule.c: use get_git_dir() instead of get_git_common_dir()
  t2405: clarify test descriptions and simplify test
  t2405: use git -C and test_commit -C instead of subshells
  t7410: rename to t2405-worktree-submodule.sh

Merge branch 'es/outside-repo-errmsg-hints' into maint

An earlier update to show the location of working tree in the error
message did not consider the possibility that a git command may be
run in a bare repository, which has been corrected.

* es/outside-repo-errmsg-hints:
  prefix_path: show gitdir if worktree unavailable
  prefix_path: show gitdir when arg is outside repo

Merge branch 'js/builtin-add-i-cmds' into maint

Minor bugfixes to "git add -i" that has recently been rewritten in C.

* js/builtin-add-i-cmds:
  built-in add -i: accept open-ended ranges again
  built-in add -i: do not try to `patch`/`diff` an empty list of files

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

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

git-gui: create a new namespace for chord script evaluation

Evaluating the script in the same namespace as the chord itself creates
potential for variable name collision. And in that case the script would
unknowingly use the chord's variables.

For example, say the script has a variable called 'is_completed', which
also exists in the chord's namespace. The script then calls 'eval' and
sets 'is_completed' to 1 thinking it is setting its own variable,
completely unaware of how the chord works behind the scenes. This leads
to the chord never actually executing because it sees 'is_completed' as
true and thinks it has already completed.

Avoid the potential collision by creating a separate namespace for the
script that is a child of the chord's namespace.

Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>

git-gui: reduce Tcl version requirement from 8.6 to 8.5

On some MacOS distributions like High Sierra, Tcl 8.5 is shipped by
default. This makes git-gui error out at startup because of the version
mismatch.

The only part that requires Tcl 8.6 is SimpleChord, which depends on
TclOO. So, don't use it and use our homegrown class.tcl instead.

This means some slight syntax changes. Since class.tcl doesn't have an
"unknown" method like TclOO does, we can't just call '$note', but have
to use '$note activate' instead. The constructor now needs a proper
namespace qualifier. Update the documentation to reflect the new syntax.

As of now, the only part of git-gui that needs Tcl 8.5 is a call to
'apply' in lib/index.tcl::lambda. Keep using it until someone shows up
shouting that their OS ships with 8.4 only. Then we would have to look
into implementing it in pure Tcl.

Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>

l10n: zh_CN: Revise v2.26.0 translation

Signed-off-by: Fangyi Zhou <me@fangyi.io>
Reviewed-by: 依云 <lilydjwg@gmail.com>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

l10n: zh_CN: for git v2.26.0 l10n round 1 and 2

Translate 79 new messages (4839t0f0u) for git 2.26.0.

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

Git 2.26-rc2

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

Merge branch 'en/test-cleanup'

Test fixes.

* en/test-cleanup:
  t6022, t6046: fix flaky files-are-updated checks

Merge branch 'es/outside-repo-errmsg-hints'

An earlier update to show the location of working tree in the error
message did not consider the possibility that a git command may be
run in a bare repository, which has been corrected.

* es/outside-repo-errmsg-hints:
  prefix_path: show gitdir if worktree unavailable

t0021: test filter metadata for additional cases

Check that we get the expected data when performing a merges or
generating archives.  Note that we don't expect a ref for merges,
because we won't be checking out any particular ref, but instead a tree
of the merged data.  For archives, however, we expect a ref as normal if
we have one.

Signed-off-by: brian m. carlson <bk2204@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/reset: compute checkout metadata for reset

Pass the commit, and if we have it, the ref to the filters when we
perform a checkout.  This should only be the case when we invoke git
reset --hard; the metadata will be unused otherwise.

Signed-off-by: brian m. carlson <bk2204@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/rebase: compute checkout metadata for rebases

Signed-off-by: brian m. carlson <bk2204@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/clone: compute checkout metadata for clones

When checking out a commit, provide metadata to the filter process
including the ref we're using.

Signed-off-by: brian m. carlson <bk2204@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/checkout: compute checkout metadata for checkouts

Provide commit metadata for checkout code paths that use unpack_trees
and friends.  When we're checking out a commit, use the commit
information, but don't provide commit information if we're checking out
from the index, since there need not be any particular commit associated
with the index, and even if there is one, we can't know what it is.

Signed-off-by: brian m. carlson <bk2204@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

convert: provide additional metadata to filters

Now that we have the codebase wired up to pass any additional metadata
to filters, let's collect the additional metadata that we'd like to
pass.

The two main places we pass this metadata are checkouts and archives.
In these two situations, reading HEAD isn't a valid option, since HEAD
isn't updated for checkouts until after the working tree is written and
archives can accept an arbitrary tree.  In other situations, HEAD will
usually reflect the refname of the branch in current use.

We pass a smaller amount of data in other cases, such as git cat-file,
where we can really only logically know about the blob.

This commit updates only the parts of the checkout code where we don't
use unpack_trees.  That function and callers of it will be handled in a
future commit.

In the archive code, we leak a small amount of memory, since nothing we
pass in the archiver argument structure is freed.

Signed-off-by: brian m. carlson <bk2204@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

convert: permit passing additional metadata to filter processes

There are a variety of situations where a filter process can make use of
some additional metadata.  For example, some people find the ident
filter too limiting and would like to include the commit or the branch
in their smudged files.  This information isn't available during
checkout as HEAD hasn't been updated at that point, and it wouldn't be
available in archives either.

Let's add a way to pass this metadata down to the filter.  We pass the
blob we're operating on, the treeish (preferring the commit over the
tree if one exists), and the ref we're operating on.  Note that we won't
pass this information in all cases, such as when renormalizing or when
we're performing diffs, since it doesn't make sense in those cases.

The data we currently get from the filter process looks like the
following:

  command=smudge
  pathname=git.c
  0000

With this change, we'll get data more like this:

  command=smudge
  pathname=git.c
  refname=refs/tags/v2.25.1
  treeish=c522f061d551c9bb8684a7c3859b2ece4499b56b
  blob=7be7ad34bd053884ec48923706e70c81719a8660
  0000

There are a couple things to note about this approach.  For operations
like checkout, treeish will always be a commit, since we cannot check
out individual trees, but for other operations, like archive, we can end
up operating on only a particular tree, so we'll provide only a tree as
the treeish.  Similar comments apply for refname, since there are a
variety of cases in which we won't have a ref.

This commit wires up the code to print this information, but doesn't
pass any of it at this point.  In a future commit, we'll have various
code paths pass the actual useful data down.

Signed-off-by: brian m. carlson <bk2204@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: vi(4839t): Updated Vietnamese translation for v2.26.0

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

l10n: vi: fix translation + grammar

- context should be translated to ngữ cảnh instead of nội dung
- add missing accents
- switch adjective and secondary objects position:
* The formatted English text will be "To remove '+/-' lines",
it should be translated to "Để bỏ dòng bắt đầu với '+/-'

Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>

oidset: remove unnecessary include

When commit 8b2f8cbcb1 ("oidset: use khash", 2018-10-04) moved from
using oidmap to khash, it replaced the oidmap.h include with both one
for hashmap.h and khash.h.  Since the hashmap.h header is unnecessary,
and the point of the patch was to switch from hashmap (used by oidmap)
to khash.h, remove the unneccessary include.

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

connected.c: reprepare packs for corner cases

While updating the microsoft/git fork on top of v2.26.0-rc0 and
consuming that build into Scalar, I noticed a corner case bug around
partial clone.

The "scalar clone" command can create a Git repository with the
proper config for using partial clone with the "blob:none" filter.
Instead of calling "git clone", it runs "git init" then sets a few
more config values before running "git fetch".

In our builds on v2.26.0-rc0, we noticed that our "git fetch"
command was failing with

  error: https://github.com/microsoft/scalar did not send all necessary objects

This does not happen if you copy the config file from a repository
created by "git clone --filter=blob:none <url>", but it does happen
when adding the config option "core.logAllRefUpdates = true".

By debugging, I was able to see that the loop inside
check_connnected() that checks if all refs are contained in
promisor packs actually did not have any packfiles in the packed_git
list.

I'm not sure what corner-case issues caused this config option to
prevent the reprepare_packed_git() from being called at the proper
spot during the fetch operation. This approach requires a situation
where we use the remote helper process, which makes it difficult to
test.

It is possible to place a reprepare_packed_git() call in the fetch code
closer to where we receive a pack, but that leaves an opening for a
later change to re-introduce this problem. Further, a concurrent repack
operation could replace the pack-file list we already loaded into
memory, causing this issue in an even harder to reproduce scenario.

It is really the responsibility of anyone looping through the list of
pack-files for a certain object to fall back to reprepare_packed_git()
on a fail-to-find. The loop in check_connected() does not have this
fallback, leading to this bug.

We _could_ try looping through the packs and only reprepare the packs
after a miss, but that change is more involved and has little value.
Since this case is isolated to the case when
opt->check_refs_are_promisor_objects_only is true, we are confident that
we are verifying the refs after downloading new data. This implies that
calling reprepare_packed_git() in advance is not a huge cost compared to
the rest of the operations already made.

Helped-by: Jeff King <peff@peff.net>
Helped-by: Junio Hamano <gitster@pobox.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gpg-interface: prefer check_signature() for GPG verification

This commit refactors the use of verify_signed_buffer() outside of
gpg-interface.c to use check_signature() instead.  It also turns
verify_signed_buffer() into a file-local function since it's now only
invoked internally by check_signature().

There were previously two globally scoped functions used in different
parts of Git to perform GPG signature verification:
verify_signed_buffer() and check_signature().  Now only
check_signature() is used.

The verify_signed_buffer() function doesn't guard against duplicate
signatures as described by Michał Górny [1].  Instead it only ensures a
non-erroneous exit code from GPG and the presence of at least one
GOODSIG status field.  This stands in contrast with check_signature()
that returns an error if more than one signature is encountered.

The lower degree of verification makes the use of verify_signed_buffer()
problematic if callers don't parse and validate the various parts of the
GPG status message themselves.  And processing these messages seems like
a task that should be reserved to gpg-interface.c with the function
check_signature().

Furthermore, the use of verify_signed_buffer() makes it difficult to
introduce new functionality that relies on the content of the GPG status
lines.

Now all operations that does signature verification share a single entry
point to gpg-interface.c.  This makes it easier to propagate changed or
additional functionality in GPG signature verification to all parts of
Git, without having odd edge-cases that don't perform the same degree of
verification.

[1] https://dev.gentoo.org/~mgorny/articles/attack-on-git-signature-verification.html

Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t: increase test coverage of signature verification output

There weren't any tests for unsuccessful signature verification of
signed merge tags shown in 'git log'.  There also weren't any tests for
the GPG output from 'git fmt-merge-msg'.  This was noticed while
investigating a buggy refactor that slipped through the test suite; see
commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c.

This commit adds signature verification tests to the 'log' and
'fmt-merge-msg' builtins.

Thanks to Linus Torvalds for reporting and finding the (now reverted)
commit that introduced the regression.

Note that the "log --show-signature for merged tag with GPG failure"
test case is really hacky.  It relies on an implementation detail of
verify_signed_buffer() -- namely, it assumes that the signature is
written to a temporary file whose path is under TMPDIR.

The rationale for that test case is to check whether the code path that
yields the "No signature" message is reachable on failure.  The
functionality in log-tree.c that may show this message does some
pre-parsing of a possible signature that prevents the GPG interface from
being invoked if a signature is actually missing.  And I haven't been
able to construct a signature that both 1. satisfies that
pre-processing, and 2. causes GPG to fail without any sort of output on
stderr along the lines of "this is a bogus/corrupt/... signature" (the
"No signature" message should only be shown if GPG produce no output).

Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
[jc: fixed missing test title noticed by Dscho]
Signed-off-by: Junio C Hamano <gitster@pobox.com>

prefix_path: show gitdir if worktree unavailable

If there is no worktree at present, we can still hint the user about
Git's current directory by showing them the absolute path to the Git
directory. Even though the Git directory doesn't make it as easy to
locate the worktree in question, it can still help a user figure out
what's going on while developing a script.

This fixes a segmentation fault introduced in e0020b2f
("prefix_path: show gitdir when arg is outside repo", 2020-02-14).

Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
[jc: added minimum tests, with help from Szeder Gábor]
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: zh_TW.po: v2.26.0 round 2 (0 untranslated)

Revision 2.

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

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

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

Merge branch 'js/askpass-coerce-utf8'

Askpass can now send non-ASCII to Git on Windows.

* js/askpass-coerce-utf8:
  git-gui--askpass: coerce answers to UTF-8 on Windows

git-gui--askpass: coerce answers to UTF-8 on Windows

This addresses the issue where Git for Windows asks the user for a
password, no credential helper is available, and then Git fails to pick
up non-ASCII characters from the Git GUI helper.

This can be verified e.g. via

echo host=http://abc.com |
git -c credential.helper= credential fill

and then pasting some umlauts.

The underlying reason is that Git for Windows tries to communicate using
the UTF-8 encoding no matter what the actual current code page is. So
let's indulge Git for Windows and do use that encoding.

This fixes https://github.com/git-for-windows/git/issues/2215

Signed-off-by: Luke Bonanomi <lbonanomi@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>

Merge branch 'py/blame-status-error'

Fixes an error popup in blame because of a missing closing bracket.

* py/blame-status-error:
  git-gui: fix error popup when doing blame -> "Show History Context"

t6022, t6046: fix flaky files-are-updated checks

Several tests wanted to verify that files were actually modified by a
merge, which it would do by checking that the mtime was updated.  In
order to avoid problems with the merge completing so fast that the mtime
at the beginning and end of the operation was the same, these tests
would first set the mtime of a file to something "old".  This "old"
value was usually determined as current system clock minus one second,
truncated to the nearest integer.  Unfortunately, it appears the system
clock and filesystem clock are different and comparing across the two
runs into race problems resulting in flaky tests.

From https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond:

    date will call the gettimeofday system call which will always return
    the most accurate time available based on the cached kernel time,
    adjusted by the CPU cycle time if available to give nanosecond
    resolution. The timestamps stored in the file system however, are
    only based on the cached kernel time. ie The time calculated at the
    last timer interrupt.

and from https://apenwarr.ca/log/20181113:

    Does mtime get set to >= the current time?

    No, this depends on clock granularity. For example, gettimeofday()
    can return times in microseconds on my system, but ext4 rounds
    timestamps down to the previous ~10ms (but not exactly 10ms)
    increment, with the surprising result that a newly-created file is
    almost always created in the past:

      $ python -c "
      import os, time
      t0 = time.time()
      open('testfile', 'w').close()
      print os.stat('testfile').st_mtime - t0
      "

      -0.00234484672546

So, instead of trying to compare across what are effectively two
different clocks, just avoid using the system clock.  Any new updates to
files have to give an mtime at least as big as what is already in the
file, so we could define "old" as one second before the mtime found in
the file before the merge starts.  But, to avoid problems with leap
seconds, ntp updates, filesystems that only provide two second
resolution, and other such weirdness, let's just pick an hour before the
mtime found in the file before the merge starts.

Also, clarify in one test where we check the mtime of different files
that it really was intentional.  I totally forgot the reasons for that
and assumed it was a bug when asked.

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

Hopefully the final batch before -rc2

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