Merge branch 'js/bundle-verify-require-object-store'

"git bundle verify" needs to see if prerequisite objects exist in
the receiving repository, but the command did not check if we are
in a repository upfront, which has been corrected.

* js/bundle-verify-require-object-store:
  bundle verify: error out if called without an object database

Merge branch 'js/bisect-helper-check-get-oid-return-value'

Code cleanup.

* js/bisect-helper-check-get-oid-return-value:
  bisect--helper: verify HEAD could be parsed before continuing

Merge branch 'jk/am-i-resolved-fix'

"git am -i --resolved" segfaulted after trying to see a commit as
if it were a tree, which has been corrected.

* jk/am-i-resolved-fix:
  am: fix --interactive HEAD tree resolution
  am: drop tty requirement for --interactive
  am: read interactive input from stdin
  am: simplify prompt response handling

Merge branch 'jk/HEAD-symref-in-xfer-namespaces'

The server side support for "git fetch" used to show incorrect
value for the HEAD symbolic ref when the namespace feature is in
use, which has been corrected.

* jk/HEAD-symref-in-xfer-namespaces:
  upload-pack: strip namespace from symref data

Merge branch 'ew/server-info-remove-crufts'

"git update-server-info" used to leave stale packfiles in its
output, which has been corrected.

* ew/server-info-remove-crufts:
  server-info: do not list unlinked packs

Merge branch 'es/grep-require-name-when-needed'

More parameter validation.

* es/grep-require-name-when-needed:
  grep: fail if call could output and name is null

Merge branch 'es/git-debugger-doc'

Doc update.

* es/git-debugger-doc:
  doc: hint about GIT_DEBUGGER in CodingGuidelines

Merge branch 'ds/object-info-for-prefetch-fix'

Code cleanup and futureproof.

* ds/object-info-for-prefetch-fix:
  sha1-file: split OBJECT_INFO_FOR_PREFETCH

The first batch after 2.22

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

Merge branch 'pw/rebase-edit-message-for-replayed-merge'

A "merge -c" instruction during "git rebase --rebase-merges" should
give the user a chance to edit the log message, even when there is
otherwise no need to create a new merge and replace the existing
one (i.e. fast-forward instead), but did not.  Which has been
corrected.

* pw/rebase-edit-message-for-replayed-merge:
  rebase -r: always reword merge -c

Merge branch 'ab/deprecate-R-for-dynpath'

The way of specifying the path to find dynamic libraries at runtime
has been simplified.  The old default to pass -R/path/to/dir has been
replaced with the new default to pass -Wl,-rpath,/path/to/dir,
which is the more recent GCC uses.  Those who need to build with an
old GCC can still use "CC_LD_DYNPATH=-R"

* ab/deprecate-R-for-dynpath:
  Makefile: remove the NO_R_TO_GCC_LINKER flag

Merge branch 'mh/import-transport-fd-fix'

The ownership rule for the file descriptor to fast-import remote
backend was mixed up, leading to unrelated file descriptor getting
closed, which has been fixed.

* mh/import-transport-fd-fix:
  Use xmmap_gently instead of xmmap in use_pack
  dup() the input fd for fast-import used for remote helpers

Merge branch 'ew/update-server-info'

"git update-server-info" learned not to rewrite the file with the
same contents.

* ew/update-server-info:
  update-server-info: avoid needless overwrites

Merge branch 'jk/help-unknown-ref-fix'

Improve the code to show args with potential typo that cannot be
interpreted as a commit-ish.

* jk/help-unknown-ref-fix:
  help_unknown_ref(): check for refname ambiguity
  help_unknown_ref(): duplicate collected refnames

Merge branch 'dl/format-patch-notes-config'

"git format-patch" learns a configuration to set the default for
its --notes=<ref> option.

* dl/format-patch-notes-config:
  format-patch: teach format.notes config option
  git-format-patch.txt: document --no-notes option

Merge branch 'nd/merge-quit'

"git merge" learned "--quit" option that cleans up the in-progress
merge while leaving the working tree and the index still in a mess.

* nd/merge-quit:
  merge: add --quit
  merge: remove drop_save() in favor of remove_merge_branch_state()

Merge branch 'ab/fail-prereqs-in-test'

Developer support to emulate unsatisfied prerequisites in tests to
ensure that the remainer of the tests still succeeds when tests
with prerequisites are skipped.

* ab/fail-prereqs-in-test:
  tests: add a special setup where prerequisites fail

Merge branch 'nd/corrupt-worktrees'

"git worktree add" used to fail when another worktree connected to
the same repository was corrupt, which has been corrected.

* nd/corrupt-worktrees:
  worktree add: be tolerant of corrupt worktrees

Merge branch 'js/rebase-cleanup'

Update supporting parts of "git rebase" to remove code that should
no longer be used.

* js/rebase-cleanup:
  rebase: fold git-rebase--common into the -p backend
  sequencer: the `am` and `rebase--interactive` scripts are gone
  .gitignore: there is no longer a built-in `git-rebase--interactive`
  t3400: stop referring to the scripted rebase
  Drop unused git-rebase--am.sh

Merge branch 'nd/worktree-name-sanitization'

In recent versions of Git, per-worktree refs are exposed in
refs/worktrees/<wtname>/ hierarchy, which means that worktree names
must be a valid refname component.  The code now sanitizes the names
given to worktrees, to make sure these refs are well-formed.

* nd/worktree-name-sanitization:
  worktree add: sanitize worktree names

Merge branch 'en/fast-export-encoding'

The "git fast-export/import" pair has been taught to handle commits
with log messages in encoding other than UTF-8 better.

* en/fast-export-encoding:
  fast-export: do automatic reencoding of commit messages only if requested
  fast-export: differentiate between explicitly UTF-8 and implicitly UTF-8
  fast-export: avoid stripping encoding header if we cannot reencode
  fast-import: support 'encoding' commit header
  t9350: fix encoding test to actually test reencoding

Merge branch 'jk/unused-params-final-batch'

* jk/unused-params-final-batch:
  verify-commit: simplify parameters to run_gpg_verify()
  show-branch: drop unused parameter from show_independent()
  rev-list: drop unused void pointer from finish_commit()
  remove_all_fetch_refspecs(): drop unused "remote" parameter
  receive-pack: drop unused "commands" from prepare_shallow_update()
  pack-objects: drop unused rev_info parameters
  name-rev: drop unused parameters from is_better_name()
  mktree: drop unused length parameter
  wt-status: drop unused status parameter
  read-cache: drop unused parameter from threaded load
  clone: drop dest parameter from copy_alternates()
  submodule: drop unused prefix parameter from some functions
  builtin: consistently pass cmd_* prefix to parse_options
  cmd_{read,write}_tree: rename "unused" variable that is used

Merge branch 'sb/format-patch-base-patch-id-fix'

The "--base" option of "format-patch" computed the patch-ids for
prerequisite patches in an unstable way, which has been updated to
compute in a way that is compatible with "git patch-id --stable".

* sb/format-patch-base-patch-id-fix:
  format-patch: make --base patch-id output stable
  format-patch: inform user that patch-id generation is unstable

Merge branch 'nd/init-relative-template-fix'

A relative pathname given to "git init --template=<path> <repo>"
ought to be relative to the directory "git init" gets invoked in,
but it instead was made relative to the repository, which has been
corrected.

* nd/init-relative-template-fix:
  init: make --template path relative to $CWD

Merge branch 'ab/send-email-transferencoding-fix'

Since "git send-email" learned to take 'auto' as the value for the
transfer-encoding, it by mistake stopped honoring the values given
to the configuration variables sendemail.transferencoding and/or
sendemail.<ident>.transferencoding.  This has been corrected to
(finally) redoing the order of setting the default, reading the
configuration and command line options.

* ab/send-email-transferencoding-fix:
  send-email: fix regression in sendemail.identity parsing
  send-email: document --no-[to|cc|bcc]
  send-email: fix broken transferEncoding tests
  send-email: remove cargo-culted multi-patch pattern in tests
  send-email: do defaults -> config -> getopt in that order
  send-email: rename the @bcclist variable for consistency
  send-email: move the read_config() function above getopts

Git 2.22

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

Merge tag 'l10n-2.22.0-rnd3' of git://github.com/git-l10n/git-po

l10n-2.22.0-rnd3

* tag 'l10n-2.22.0-rnd3' of git://github.com/git-l10n/git-po: (25 commits)
  l10n: fr.po: Review French translation
  l10n: de.po: Update German translation
  l10n: de.po: improve description of 'git reset --quiet'
  l10n: TEAMS: Change German translation team leader
  l10n: bg.po: Updated Bulgarian translation (4581t)
  l10n: zh_CN: Revision for git v2.22.0 l10n
  l10n: zh_CN: for git v2.22.0 l10n round 1~3
  l10n: es: 2.22.0 round 3
  l10n: it.po: Updated Italian translation
  l10n: fr v2.22.0 rnd 3
  l10n: vi.po(4581t): Updated Vietnamese translation for v2.22.0 round 3
  l10n: git.pot: v2.22.0 round 3 (3 new, 2 removed)
  l10n: es: 2.22.0 round 2
  l10n: bg.po: Updated Bulgarian translation (4580t)
  l10n: vi.po(4580t): Updated Vietnamese translation for v2.22.0 round 2
  l10n: fr.po v2.22.0 round 2
  l10n: git.pot: v2.22.0 round 2 (6 new, 3 removed)
  l10n: bg.po: Updated Bulgarian translation (4577t)
  l10n: es: 2.22.0 round 1
  l10n: vi.po(4577t): Updated Vietnamese translation for v2.22.0 round 1
  ...

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

* 'fr_review' of git://github.com/jnavila/git:
  l10n: fr.po: Review French translation

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

* 'master' of git://github.com/alshopov/git-po:
  l10n: bg.po: Updated Bulgarian translation (4581t)

l10n: fr.po: Review French translation

Signed-off-by: Cédric Malard <c.malard-git@valdun.net>
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>

Merge branch 'en/merge-directory-renames-fix'

Recent code restructuring of merge-recursive engine introduced a
regression dealing with rename/add conflict.

* en/merge-directory-renames-fix:
  merge-recursive: restore accidentally dropped setting of path

l10n: de.po: Update German translation

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

l10n: de.po: improve description of 'git reset --quiet'

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

l10n: TEAMS: Change German translation team leader

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

merge-recursive: restore accidentally dropped setting of path

In commit 8daec1df03de ("merge-recursive: switch from (oid,mode) pairs
to a diff_filespec", 2019-04-05), we actually switched from
(oid,mode,path) triplets to a diff_filespec -- but most callsites in the
patch only needed to worry about oid and mode so the commit message
focused on that.  The oversight in the commit message apparently spilled
over to the code as well; one of the dozen or so callsites accidentally
dropped the setting of the path in the conversion.  Restore the path
setting in that location.

Also, this pointed out that our testsuite was lacking a good rename/add
test, at least one that involved the need for merge content with the
rename.  Add such a test, and since rename/add vs. add/rename could
possibly be important, redo the merge the opposite direction to make
sure we don't have issues with the direction of the merge.  These
testcases failed before restoring the setting of path, but with the
paths appropriately set the testcases both pass.

Reported-by: Ben Humphreys <behumphreys@atlassian.com>
Based-on-patch-by: SZEDER Gábor <szeder.dev@gmail.com>
Tested-by: Ben Humphreys <behumphreys@atlassian.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

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

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

l10n: zh_CN: Revision for git v2.22.0 l10n

Revise 51 translations, improving consistency for some phrased.
Update email address for Fangyi Zhou

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

l10n: zh_CN: for git v2.22.0 l10n round 1~3

Translate 274 new messages (4581t0f0u) for git 2.22.0.

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

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

* '2.22' of https://github.com/ChrisADR/git-po:
  l10n: es: 2.22.0 round 3

Merge branch 'it-l10n-wip' of github.com:AlessandroMenti/git-po

* 'it-l10n-wip' of github.com:AlessandroMenti/git-po:
  l10n: it.po: Updated Italian translation

l10n: es: 2.22.0 round 3

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

l10n: it.po: Updated Italian translation

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

l10n: fr v2.22.0 rnd 3

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

l10n: vi.po(4581t): Updated Vietnamese translation for v2.22.0 round 3

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

l10n: git.pot: v2.22.0 round 3 (3 new, 2 removed)

Generate po/git.pot from v2.22.0-rc3 for git v2.22.0 l10n round 3.

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

Merge branch 'master' of git://git./git/git

* 'master' of git://git.kernel.org/pub/scm/git/git:
  Git 2.22-rc3
  i18n: fix typos found during l10n for git 2.22.0
  RelNotes: minor typo fixes in 2.22.0 draft
  list-objects-filter: disable 'sparse:path' filters

Git 2.22-rc3

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

Merge branch 'cc/list-objects-filter-wo-sparse-path'

Disable "--filter=sparse:path=<path>" that would allow reading from
paths on the filesystem.

* cc/list-objects-filter-wo-sparse-path:
  list-objects-filter: disable 'sparse:path' filters

i18n: fix typos found during l10n for git 2.22.0

Fix two typos introduced by the following commits:

+ 31fba9d3b4 (diff-parseopt: convert --[src|dst]-prefix, 2019-03-24)
+ ed8b4132c8 (remote-curl: mark all error messages for translation,
  2019-03-05)

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

RelNotes: minor typo fixes in 2.22.0 draft

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

l10n: es: 2.22.0 round 2

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

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

* 'master' of https://github.com/vnwildman/git:
  l10n: vi.po(4580t): Updated Vietnamese translation for v2.22.0 round 2

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

* 'master' of git://github.com/alshopov/git-po:
  l10n: bg.po: Updated Bulgarian translation (4580t)

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

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

l10n: vi.po(4580t): Updated Vietnamese translation for v2.22.0 round 2

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

l10n: fr.po v2.22.0 round 2

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

l10n: git.pot: v2.22.0 round 2 (6 new, 3 removed)

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

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

Merge branch 'master' of git://git./git/git

* 'master' of git://git.kernel.org/pub/scm/git/git: (66 commits)
  Git 2.22-rc2
  ...

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

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

Git 2.22-rc2

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

Merge branch 'js/rebase-config-bitfix'

* js/rebase-config-bitfix:
  rebase: replace incorrect logical negation by correct bitwise one

Merge branch 'es/doc-gitsubmodules-markup'

Doc markup fix.

* es/doc-gitsubmodules-markup:
  gitsubmodules: align html and nroff lists

Merge branch 'ja/diff-opt-typofix'

Typofix.

* ja/diff-opt-typofix:
  diff: fix mistake in translatable strings

Merge branch 'jt/clone-server-option'

A brown-paper-bag bugfix to a change already in 'master'.

* jt/clone-server-option:
  fetch-pack: send server options after command

Merge branch 'sg/progress-off-by-one-fix'

A brown-paper-bag bugfix to a change already in 'master'.

* sg/progress-off-by-one-fix:
  progress: avoid empty line when breaking the progress line

Merge branch 'js/rebase-deprecate-preserve-merges'

A bit more leftover clean-up to deprepcate "rebase -p".

* js/rebase-deprecate-preserve-merges:
  rebase docs: recommend `-r` over `-p`
  docs: say that `--rebase=preserve` is deprecated
  tests: mark a couple more test cases as requiring `rebase -p`

Merge branch 'sg/trace2-rename'

Rename environment variables that are used to control the "trace2"
mechanism to a more readable name.

* sg/trace2-rename:
  trace2: document the supported values of GIT_TRACE2* env variables
  trace2: rename environment variables to GIT_TRACE2*

Merge branch 'jh/trace2'

* jh/trace2:
  trace2: fix tracing when NO_PTHREADS is defined

Merge branch 'nd/diff-parseopt'

A brown-paper-bag bugfix to a change already in 'master'.

* nd/diff-parseopt:
  parse-options: check empty value in OPT_INTEGER and OPT_ABBREV
  diff-parseopt: restore -U (no argument) behavior
  diff-parseopt: correct variable types that are used by parseopt

list-objects-filter: disable 'sparse:path' filters

If someone wants to use as a filter a sparse file that is in the
repository, something like "--filter=sparse:oid=<ref>:<path>"
already works.

So 'sparse:path' is only interesting if the sparse file is not in
the repository. In this case though the current implementation has
a big security issue, as it makes it possible to ask the server to
read any file, like for example /etc/password, and to explore the
filesystem, as well as individual lines of files.

If someone is interested in using a sparse file that is not in the
repository as a filter, then at the minimum a config option, such
as "uploadpack.sparsePathFilter", should be implemented first to
restrict the directory from which the files specified by
'sparse:path' can be read.

For now though, let's just disable 'sparse:path' filters.

Helped-by: Matthew DeVore <matvore@google.com>
Helped-by: Jeff Hostetler <git@jeffhostetler.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

parse-options: check empty value in OPT_INTEGER and OPT_ABBREV

When parsing the argument for OPT_INTEGER and OPT_ABBREV, we check if we
can parse the entire argument to a number with "if (*s)". There is one
missing check: if "arg" is empty to begin with, we fail to notice.

This could happen with long option by writing like

  git diff --inter-hunk-context= blah blah

Before 16ed6c97cc (diff-parseopt: convert --inter-hunk-context,
2019-03-24), --inter-hunk-context is handled by a custom parser
opt_arg() and does detect this correctly.

This restores the bahvior for --inter-hunk-context and make sure all
other integer options are handled the same (sane) way. For OPT_ABBREV
this is new behavior. But it makes it consistent with the rest.

PS. OPT_MAGNITUDE has similar code but git_parse_ulong() does detect
empty "arg". So it's good to go.

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

diff-parseopt: restore -U (no argument) behavior

Before d473e2e0e8 (diff.c: convert -U|--unified, 2019-01-27), -U and
--unified are implemented with a custom parser opt_arg() in diff.c. I
didn't check this code carefully and not realize that it's the
equivalent of PARSE_OPT_NONEG | PARSE_OPT_OPTARG.

In other words, if -U is specified without any argument, the option
should be accepted, and the default value should be used. Without
PARSE_OPT_OPTARG, parse_options() will reject this case and cause a
regression.

Reported-by: Bryan Turner <bturner@atlassian.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff-parseopt: correct variable types that are used by parseopt

Most number-related OPT_ macros store the value in an 'int'
variable. Many of the variables in 'struct diff_options' have a
different type, but during the conversion to using parse_options() I
failed to notice and correct.

The problem was reported on s360x which is a big-endian
architechture. The variable to store '-w' option in this case is
xdl_opts, 'long' type, 8 bytes. But since parse_options() assumes
'int' (4 bytes), it will store bits in the wrong part of xdl_opts. The
problem was found on little-endian platforms because parse_options()
will accidentally store at the right part of xdl_opts.

There aren't much to say about the type change (except that 'int' for
xdl_opts should still be big enough, since Windows' long is the same
size as 'int' and nobody has complained so far). Some safety checks may
be implemented in the future to prevent class of bugs.

Reported-by: Todd Zullinger <tmz@pobox.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-email: fix regression in sendemail.identity parsing

Fix a regression in my recent 3494dfd3ee ("send-email: do defaults ->
config -> getopt in that order", 2019-05-09). I missed that the
$identity variable needs to be extracted from the command-line before
we do the config reading, as it determines which config variable we
should read first. See [1] for the report.

The sendemail.identity feature was added back in
34cc60ce2b ("send-email: Add support for SSL and SMTP-AUTH",
2007-09-03), there were no tests to assert that it worked properly.

So let's fix both the regression, and add some tests to assert that
this is being parsed properly. While I'm at it I'm adding a
--no-identity option to go with --[to|cc|bcc] variable, since the
semantics are similar. It's like to/cc/bcc except that unlike those we
don't support multiple identities, but we could now easily add it
support for it if anyone cares.

In just fixing the --identity command-line parsing bug I discovered
that a narrow fix to that wouldn't do. In read_config() we had a state
machine that would only set config values if they weren't set already,
and thus by proxy we wouldn't e.g. set "to" based on sendemail.to if
we'd seen sendemail.gmail.to before, with --identity=gmail.

I'd modified some of the relevant code in 3494dfd3ee, but just
reverting to that wouldn't do, since it would bring back the
regression fixed in that commit.

Refactor read_config() do what we actually mean here. We don't want to
set a given sendemail.VAR if a sendemail.$identity.VAR previously set
it. The old code was conflating this desire with the hardcoded
defaults for these variables, and as discussed in 3494dfd3ee that was
never going to work. Instead pass along the state of whether an
identity config set something before, as distinguished from the state
of the default just being false, or the default being a non-bool or
true (e.g. --transferencoding).

I'm still not happy with the test coverage here, e.g. there's nothing
testing sendemail.smtpEncryption, but I only have so much time to fix
this code.

1. https://public-inbox.org/git/5cddeb61.1c69fb81.47ed4.e648@mx.google.com/

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

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

* 'master' of git://github.com/alshopov/git-po:
  l10n: bg.po: Updated Bulgarian translation (4577t)

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

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

doc: hint about GIT_DEBUGGER in CodingGuidelines

We check for a handy environment variable GIT_DEBUGGER when running via
bin-wrappers/, but this feature is undocumented. Add a hint to how to
use it into the CodingGuidelines (which is where other useful
environment settings like DEVELOPER are documented).

Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1-file: split OBJECT_INFO_FOR_PREFETCH

The OBJECT_INFO_FOR_PREFETCH bitflag was added to sha1-file.c in 0f4a4fb1
(sha1-file: support OBJECT_INFO_FOR_PREFETCH, 2019-03-29) and is used to
prevent the fetch_objects() method when enabled.

However, there is a problem with the current use. The definition of
OBJECT_INFO_FOR_PREFETCH is given by adding 32 to OBJECT_INFO_QUICK. This is
clearly stated above the definition (in a comment) that this is so
OBJECT_INFO_FOR_PREFETCH implies OBJECT_INFO_QUICK. The problem is that using
"flag & OBJECT_INFO_FOR_PREFETCH" means that OBJECT_INFO_QUICK also implies
OBJECT_INFO_FOR_PREFETCH.

Split out the single bit from OBJECT_INFO_FOR_PREFETCH into a new
OBJECT_INFO_SKIP_FETCH_OBJECT as the single bit and keep
OBJECT_INFO_FOR_PREFETCH as the union of two flags. This allows a clearer use
of flag checking while also keeping the implication of OBJECT_INFO_QUICK.

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

rebase docs: recommend `-r` over `-p`

The `--preserve-merges` option is now deprecated in favor of
`--rebase-merges`; Let's stop recommending the former.

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

docs: say that `--rebase=preserve` is deprecated

As of Git v2.22.0, the `--preserve-merges` backend of `git rebase` will
be officially deprecated in favor of the `--rebase-merges` backend.
Consequently, `git pull --rebase=preserve` will also be deprected. State
this explicitly.

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

tests: mark a couple more test cases as requiring `rebase -p`

The `--preserve-merges` option has been deprecated, and as a consequence
we started to mark test cases that require that option to be supported,
in preparation for removing that support eventually.

Since we marked those test cases, a couple more crept into the test
suite, and with this patch, we mark them, too.

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

bundle verify: error out if called without an object database

The deal with bundles is: they really are thin packs, with very little
sugar on top. So we really need a repository (or more appropriately, an
object database) to work with, when asked to verify a bundle.

Let's error out with a useful error message if `git bundle verify` is
called without such an object database to work with.

Reported by Konstantin Ryabitsev.

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

server-info: do not list unlinked packs

Having non-existent packs in objects/info/packs causes
dumb HTTP clients to abort.

v2: use single loop with ALLOC_GROW as suggested by Jeff King

Signed-off-by: Eric Wong <e@80x24.org>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch-pack: send server options after command

Currently, if any server options are specified during a protocol v2
fetch, server options will be sent before "command=fetch". Write server
options to the request buffer in send_fetch_request() so that the
components of the request are sent in the correct order.

The protocol documentation states that the command must come first. The
Git server implementation in serve.c (see process_request() in that
file) tolerates any order of command and capability, which is perhaps
why we haven't noticed this. This was noticed when testing against a
JGit server implementation, which follows the documentation in this
regard.

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

grep: fail if call could output and name is null

grep_source(), which performs much of the work for Git's grep library,
allows passing an arbitrary struct grep_source which represents the text
which grep_source() should search to match a pattern in the provided
struct grep_opt. In most callers, the grep_source::name field is set to
an appropriate prefix to print before a colon when a result matches:

README:Git is an Open Source project covered by the GNU General

One caller, grep_buffer(), leaves the grep_source::name field set to
NULL because there isn't enough context to determine an appropriate name
for this kind of output line. In practice, this has been fine: the only
caller of grep_buffer() is "git log --grep", and that caller sets
grep_opt::status_only, which disables output and only checks whether a
match exists. But this is brittle: a future caller can call
grep_buffer() without grep_opt::status_only set, and as soon as it hits
a match, grep_source() will try to print the match and segfault:

(null):Git is an Open Source project covered by the GNU General

For example, a future caller might want to print all matching lines from
commits which match a regex.

Futureproof by diagnosing early a use of the API that could trigger that
condition, before we know whether the pattern matches:

BUG: grep.c:1783: grep call which could print a name requires
grep_source.name be non-NULL
Aborted

This way, the caller's author gets an indication of how to fix the issue
- by providing grep_source::name or setting grep_opt::status_only - and
they are warned of the potential for a segfault unconditionally, rather
than only if there is a match.

Noticed while adding such a call to a tutorial on revision walks.

Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

trace2: fix tracing when NO_PTHREADS is defined

Teach trace2 TLS code to not rely on pthread_getspecific() when NO_PTHREADS
is defined.  Instead, always assume the context data of the main thread.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect--helper: verify HEAD could be parsed before continuing

In 06f5608c14e6 (bisect--helper: `bisect_start` shell function partially
in C, 2019-01-02), we introduced a call to `get_oid()` and did not check
whether it succeeded before using its output.

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

rebase: replace incorrect logical negation by correct bitwise one

In bff014dac7d9 (builtin rebase: support the `verbose` and `diffstat`
options, 2018-09-04), we added a line that wanted to remove the
`REBASE_DIFFSTAT` bit from the flags, but it used an incorrect negation.

Found by Coverity.

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

am: fix --interactive HEAD tree resolution

In --interactive mode, "git am --resolved" will try to generate a patch
based on what is in the index, so that it can prompt "apply this
patch?". To do so it needs the tree of HEAD, which it tries to get with
get_oid_tree(). However, this doesn't yield a tree object; the "tree"
part just means "if you must disambiguate short oids, then prefer trees"
(and we do not need to disambiguate at all, since we are feeding a ref).

Instead, we must parse the oid as a commit (which should always be true
in a non-corrupt repository), and access its tree pointer manually.

This has been broken since the conversion to C in 7ff2683253
(builtin-am: implement -i/--interactive, 2015-08-04), but there was no
test coverage because of interactive-mode's insistence on having a tty.
That was lifted in the previous commit, so we can now add a test for
this case.

Note that before this patch, the test would result in a BUG() which
comes from 3506dc9445 (has_uncommitted_changes(): fall back to empty
tree, 2018-07-11). But before that, we'd have simply segfaulted (and in
fact this is the exact type of case the BUG() added there was trying to
catch!).

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

am: drop tty requirement for --interactive

We have required that the stdin of "am --interactive" be a tty since
a1451104ac (git-am: interactive should fail gracefully., 2005-10-12).
However, this isn't strictly necessary, and makes the tool harder to
test (and is unlike all of our other --interactive commands).

The goal of that commit was to make sure that somebody does not do:

  git am --interactive <mbox

and cause us to read commands from the mbox. But we can simply check
up front for this case and complain before entering the interactive
loop.

Technically this disallows:

  git am --interactive </dev/null

where our lack of patches means we would never prompt for anything, and
so the old code would not notice our lack of tty (and now we'd die
early). But since such a command is totally pointless, it's no loss.

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

am: read interactive input from stdin

In the conversion of git-am from shell script to C, we switched to using
git_prompt(). Unlike the original shell command "read reply", this
doesn't read from stdin at all, but rather from /dev/tty.

In most cases this distinction wouldn't matter. We require (as the shell
script did) that stdin is a tty, so they would generally be the same
thing. But one important exception is our test suite: even with
test_terminal, we cannot test "am --interactive" because it insists on
reading from /dev/tty, not the pseudo-tty we've set up in the test
script.

Fixing this clears the way to adding tests in a future patch.

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

am: simplify prompt response handling

We'll never see a NULL returned from git_prompt(); if it can't produce
any input for us (e.g., because the terminal got EOF) then it will just
die().

So there's no need for us to handle NULL here. And even if there was, it
doesn't make sense to continue; on a true terminal hangup we'd just loop
infinitely trying to get input that will never come.

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

progress: avoid empty line when breaking the progress line

Since commit 545dc345eb (progress: break too long progress bar lines,
2019-04-12) when splitting a too long progress line, sometimes it
looks as if a superfluous empty line were added between the title
line and the counters.

To make sure that the previously displayed progress line is completely
covered up when writing the new, shorter title line, we calculate how
many characters need to be overwritten with spaces.  Alas, this
calculation doesn't account for the newline character at the end of
the new title line, and resulted in printing one more space than
strictly necessary.  This extra space character doesn't matter, if the
length of the previous progress line was shorter than the width of the
terminal.  However, if the previous line matched the terminal width,
then this extra space made the new line longer, effectively adding
that empty line after the title line.

Fix this off-by-one to avoid that spurious empty line.

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

trace2: document the supported values of GIT_TRACE2* env variables

The descriptions of the GIT_TRACE2* environment variables link to the
technical docs for further details on the supported values.  However,
a link like this only really works if the docs are viewed in a browser
and the full documentation is available.  OTOH, in 'man git' there are
no links to conveniently click on, and distro-shipped git packages
tend to include only the man pages, while the technical docs and the
docs in html format are in a separate 'git-doc' package.

So let's describe the supported values to make the manpage more
self-contained, but still keep the references to the technical docs
because the details of the SID, and the JSON and perf output formats
are definitely beyond the scope of 'man git'.

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

trace2: rename environment variables to GIT_TRACE2*

For an environment variable that is supposed to be set by users, the
GIT_TR2* env vars are just too unclear, inconsistent, and ugly.

Most of the established GIT_* environment variables don't use
abbreviations, and in case of the few that do (GIT_DIR,
GIT_COMMON_DIR, GIT_DIFF_OPTS) it's quite obvious what the
abbreviations (DIR and OPTS) stand for.  But what does TR stand for?
Track, traditional, trailer, transaction, transfer, transformation,
transition, translation, transplant, transport, traversal, tree,
trigger, truncate, trust, or ...?!

The trace2 facility, as the '2' suffix in its name suggests, is
supposed to eventually supercede Git's original trace facility.  It's
reasonable to expect that the corresponding environment variables
follow suit, and after the original GIT_TRACE variables they are
called GIT_TRACE2; there is no such thing is 'GIT_TR'.

All trace2-specific config variables are, very sensibly, in the
'trace2' section, not in 'tr2'.

OTOH, we don't gain anything at all by omitting the last three
characters of "trace" from the names of these environment variables.

So let's rename all GIT_TR2* environment variables to GIT_TRACE2*,
before they make their way into a stable release.

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

upload-pack: strip namespace from symref data

Since 7171d8c15f (upload-pack: send symbolic ref information as
capability, 2013-09-17), we've sent cloning and fetching clients special
information about which branch HEAD is pointing to, so that they don't
have to guess based on matching up commit ids.

However, this feature has never worked properly with the GIT_NAMESPACE
feature.  Because upload-pack uses head_ref_namespaced(find_symref), we
do find and report on refs/namespaces/foo/HEAD instead of the actual
HEAD of the repo. This makes sense, since the branch pointed to by the
top-level HEAD may not be advertised at all. But we do two things wrong:

  1. We report the full name refs/namespaces/foo/HEAD, instead of just
     HEAD. Meaning no client is going to bother doing anything with that
     symref, since we're not otherwise advertising it.

  2. We report the symref destination using its full name (e.g.,
     refs/namespaces/foo/refs/heads/master). That's similarly useless to
     the client, who only saw "refs/heads/master" in the advertisement.

We should be stripping the namespace prefix off of both places (which
this patch fixes).

Likely nobody noticed because we tend to do the right thing anyway. Bug
(1) means that we said nothing about HEAD (just refs/namespace/foo/HEAD).
And so the client half of the code, from a45b5f0552 (connect: annotate
refs with their symref information in get_remote_head(), 2013-09-17),
does not annotate HEAD, and we use the fallback in guess_remote_head(),
matching refs by object id. Which is usually right. It only falls down
in ambiguous cases, like the one laid out in the included test.

This also means that we don't have to worry about breaking anybody who
was putting pre-stripped names into their namespace symrefs when we fix
bug (2). Because of bug (1), nobody would have been using the symref we
advertised in the first place (not to mention that those symrefs would
have appeared broken for any non-namespaced access).

Note that we have separate fixes here for the v0 and v2 protocols. The
symref advertisement moved in v2 to be a part of the ls-refs command.
This actually gets part (1) right, since the symref annotation
piggy-backs on the existing ref advertisement, which is properly
stripped. But it still needs a fix for part (2). The included tests
cover both protocols.

Reported-by: Bryan Turner <bturner@atlassian.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitsubmodules: align html and nroff lists

There appears to be a bug in the toolchain generating manpages from
lettered lists. When a list is enumerated with letters, the resulting
nroff shows numbers instead. Mostly this is harmless, but in the case of
gitsubmodules, the paragraph following the list refers back to each
bullet by letter. As a result, reading this documentation via `man
gitsubmodules` is hard to parse - readers must infer that a bug exists
and a refers to 1, b refers to 2, and c refers to 3 in the list above.

The problem specifically was introduced in ad47194; previously rather
than generating numerated lists the bulleted area was entirely
monospaced in HTML and shown in plaintext in nroff.

The bug seems to exist in docbook-xml - I've reported it on May 1 via
the docbook-apps mail list - but for now it may make more sense to just
work around the issue.

Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: es: 2.22.0 round 1

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

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

* 'master' of https://github.com/vnwildman/git:
  l10n: vi.po(4577t): Updated Vietnamese translation for v2.22.0 round 1

Git 2.22-rc1

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