Third batch

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

Merge branch 'tb/receive-pack-code-cleanup'

Code clean-up.

* tb/receive-pack-code-cleanup:
  builtin/receive-pack.c: remove redundant 'if'

Merge branch 'jc/avoid-redundant-submodule-fetch'

"git fetch --recurse-submodules" from multiple remotes (either from
a remote group, or "--all") used to make one extra "git fetch" in
the submodules, which has been corrected.

* jc/avoid-redundant-submodule-fetch:
  fetch: do not run a redundant fetch from submodule

Merge branch 'os/fetch-check-not-current-branch'

The way "git fetch" without "--update-head-ok" ensures that HEAD in
no worktree points at any ref being updated was too wasteful, which
has been optimized a bit.

* os/fetch-check-not-current-branch:
  fetch: limit shared symref check only for local branches

Merge branch 'pb/ggg-in-mfc-doc'

Documentation update.

* pb/ggg-in-mfc-doc:
  MyFirstContribution: drop PR description for GGG single-patch contributions
  MyFirstContribution: reference "The cover letter" in GitGitGadget section
  MyFirstContribution: reference "The cover letter" in "Preparing Email"
  MyFirstContribution: add standalone section on cover letter
  MyFirstContribution: add "Anatomy of a Patch Series" section

Merge branch 'jt/fetch-peek-optional-section'

"git fetch" unnecessarily failed when an unexpected optional
section appeared in the output, which has been corrected.

* jt/fetch-peek-optional-section:
  fetch-pack: make unexpected peek result non-fatal

Merge branch 'jc/show-branch-g-current'

The "--current" option of "git show-branch" should have been made
incompatible with the "--reflog" mode, but this was not enforced,
which has been corrected.

* jc/show-branch-g-current:
  show-branch: -g and --current are incompatible

Merge branch 'ep/coverage-report-wants-test-to-have-run'

"make coverage-report" without first running "make coverage" did
not produce any meaningful result, which has been corrected.

* ep/coverage-report-wants-test-to-have-run:
  Makefile: add a prerequisite to the coverage-report target

Second batch

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

Merge branch 'jc/archive-add-file-normalize-mode'

"git archive --add-file=<path>" picked up the raw permission bits
from the path and propagated to zip output in some cases, without
normalization, which has been corrected (tar output did not have
this issue).

* jc/archive-add-file-normalize-mode:
  archive: do not let on-disk mode leak to zip archives

Merge branch 'ab/valgrind-fixes'

A bit of test framework fixes with a few fixes to issues found by
valgrind.

* ab/valgrind-fixes:
  commit-graph.c: don't assume that stat() succeeds
  object-file: fix a unpack_loose_header() regression in 3b6a8db3b03
  log test: skip a failing mkstemp() test under valgrind
  tests: using custom GIT_EXEC_PATH breaks --valgrind tests

Merge branch 'ab/commit-plug-leaks'

Leakfix in the top-level called-once function.

* ab/commit-plug-leaks:
  commit: fix "author_ident" leak

First batch for 2.37

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

Merge branch 'cb/ci-make-p4-optional'

macOS CI jobs have been occasionally flaky due to tentative version
skew between perforce and the homebrew packager.  Instead of
failing the whole CI job, just let it skip the p4 tests when this
happens.

* cb/ci-make-p4-optional:
  ci: use https, not http to download binaries from perforce.com
  ci: reintroduce prevention from perforce being quarantined in macOS
  ci: avoid brew for installing perforce
  ci: make failure to find perforce more user friendly

Merge branch 'tk/p4-metadata-coding-strategies'

"git p4" updates.

* tk/p4-metadata-coding-strategies:
  git-p4: improve encoding handling to support inconsistent encodings

Merge branch 'ep/equals-null-cocci'

Merges up ep/maint-equals-null-cocci to the current codebase.

* ep/equals-null-cocci:
  tree-wide: apply equals-null.cocci

Merge branch 'ep/maint-equals-null-cocci'

Introduce and apply coccinelle rule to discourage an explicit
comparison between a pointer and NULL, and applies the clean-up to
the maintenance track.

* ep/maint-equals-null-cocci:
  tree-wide: apply equals-null.cocci
  tree-wide: apply equals-null.cocci
  contrib/coccinnelle: add equals-null.cocci

Merge branch 'ds/sparse-colon-path'

"git show :<path>" learned to work better with the sparse-index
feature.

* ds/sparse-colon-path:
  rev-parse: integrate with sparse index
  object-name: diagnose trees in index properly
  object-name: reject trees found in the index
  show: integrate with the sparse index
  t1092: add compatibility tests for 'git show'

Merge branch 'vd/sparse-stash'

Teach "git stash" to work better with sparse index entries.

* vd/sparse-stash:
  unpack-trees: preserve index sparsity
  stash: apply stash using 'merge_ort_nonrecursive()'
  read-cache: set sparsity when index is new
  sparse-index: expose 'is_sparse_index_allowed()'
  stash: integrate with sparse index
  stash: expand sparse-checkout compatibility testing

Merge branch 'cd/bisect-messages-from-pre-flight-states'

"git bisect" was too silent before it is ready to start computing
the actual bisection, which has been corrected.

* cd/bisect-messages-from-pre-flight-states:
  bisect: output bisect setup status in bisect log
  bisect: output state before we are ready to compute bisection

Merge branch 'jc/update-ozlabs-url'

* jc/update-ozlabs-url:
  SubmittingPatches: use more stable git.ozlabs.org URL

Merge branch 'gc/pull-recurse-submodules'

"git pull" without "--recurse-submodules=<arg>" made
submodule.recurse take precedence over fetch.recurseSubmodules by
mistake, which has been corrected.

* gc/pull-recurse-submodules:
  pull: do not let submodule.recurse override fetch.recurseSubmodules

Merge branch 'mg/detect-compiler-in-c-locale'

Build procedure fixup.

* mg/detect-compiler-in-c-locale:
  detect-compiler: make detection independent of locale

Merge branch 'js/trace2-doc-fixes'

Trace2 documentation updates.

* js/trace2-doc-fixes:
  trace2 docs: add missing full stop
  trace2 docs: clarify what `varargs` is all about
  trace2 docs: fix a JSON formatted example
  trace2 docs: surround more terms in backticks
  trace2 docs: "printf" is not an English word
  trace2 docs: a couple of grammar fixes

Merge branch 'mv/log-since-as-filter'

"git log --since=X" will stop traversal upon seeing a commit that
is older than X, but there may be commits behind it that is younger
than X when the commit was created with a faulty clock.  A new
option is added to keep digging without stopping, and instead
filter out commits with timestamp older than X.

* mv/log-since-as-filter:
  log: "--since-as-filter" option is a non-terminating "--since" variant

Merge branch 'rs/external-diff-tempfile'

The temporary files fed to external diff command are now generated
inside a new temporary directory under the same basename.

* rs/external-diff-tempfile:
  diff: use mks_tempfile_dt()
  tempfile: add mks_tempfile_dt()

Merge branch 'kf/p4-multiple-remotes'

"git p4" update.

* kf/p4-multiple-remotes:
  git-p4: fix issue with multiple perforce remotes

Merge branch 'tk/p4-with-explicity-sync'

"git p4" update.

* tk/p4-with-explicity-sync:
  git-p4: support explicit sync of arbitrary existing git-p4 refs

Merge branch 'tk/p4-utf8-bom'

"git p4" update.

* tk/p4-utf8-bom:
  git-p4: preserve utf8 BOM when importing from p4 to git

Merge branch 'cg/vscode-with-gdb'

VS code configuration updates.

* cg/vscode-with-gdb:
  contrib/vscode/: debugging with VS Code and gdb

Merge branch 'sa/t1011-use-helpers'

A GSoC practice.

* sa/t1011-use-helpers:
  t1011: replace test -f with test_path_is_file

Merge branch 'km/t3501-use-test-helpers'

Test script updates.

* km/t3501-use-test-helpers:
  t3501: remove test -f and stop ignoring git <cmd> exit code

Merge branch 'pb/submodule-recurse-mode-enum'

Small code clean-up.

* pb/submodule-recurse-mode-enum:
  submodule.h: use a named enum for RECURSE_SUBMODULES_*

Merge branch 'ah/convert-warning-message'

Update a few end-user facing messages around eol conversion.

* ah/convert-warning-message:
  convert: clarify line ending conversion warning

Merge branch 'gf/unused-includes'

Remove unused includes.

* gf/unused-includes:
  apply.c: remove unnecessary include
  serve.c: remove unnecessary include

Merge branch 'gf/shorthand-version-and-help'

"git -v" and "git -h" are now understood as "git --version" and
"git --help".

* gf/shorthand-version-and-help:
  cli: add -v and -h shorthands

Merge branch 'rs/t7812-pcre2-ws-bug-test'

A test to ensure workaround for an earlier pcre2 bug does work.

* rs/t7812-pcre2-ws-bug-test:
  t7812: test PCRE2 whitespace bug

Merge branch 'ds/do-not-call-bug-on-bad-refs'

Code clean-up.

* ds/do-not-call-bug-on-bad-refs:
  clone: die() instead of BUG() on bad refs

Merge branch 'sg/safe-directory-tests-and-docs'

New tests for the safe.directory mechanism.

* sg/safe-directory-tests-and-docs:
  safe.directory: document and check that it's ignored in the environment
  t0033-safe-directory: check when 'safe.directory' is ignored
  t0033-safe-directory: check the error message without matching the trash dir

builtin/receive-pack.c: remove redundant 'if'

In c7c4bdeccf (run-command API: remove "env" member, always use
"env_array", 2021-11-25), there was a push to replace

    cld.env = env->v;

with

    strvec_pushv(&cld.env_array, env->v);

The conversion in c7c4bdeccf was mostly plug-and-play, with the snag
that some instances of strvec_pushv() became guarded with a NULL check
to ensure that the second argument was non-NULL.

This conversion was slightly over-eager to add a conditional in
builtin/receive-pack.c::unpack(), since we know at the point that we
add the result of `tmp_objdir_env()` into the child process's
environment, that `tmp_objdir` is non-NULL.

This follows from the conditional just before our strvec_pushv() call
(which returns from the function if `tmp_objdir` was NULL), as well as
the call to tmp_objdir_add_as_alternate() just below, which relies on
its argument (`tmp_objdir`) being non-NULL.

In the meantime, this extra conditional isn't hurting anything. But it
is redundant and thus unnecessarily confusing. So let's remove it.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: do not run a redundant fetch from submodule

When 7dce19d3 (fetch/pull: Add the --recurse-submodules option,
2010-11-12) introduced the "--recurse-submodule" option, the
approach taken was to perform fetches in submodules only once, after
all the main fetching (it may usually be a fetch from a single
remote, but it could be fetching from a group of remotes using
fetch_multiple()) succeeded.  Later we added "--all" to fetch from
all defined remotes, which complicated things even more.

If your project has a submodule, and you try to run "git fetch
--recurse-submodule --all", you'd see a fetch for the top-level,
which invokes another fetch for the submodule, followed by another
fetch for the same submodule.  All but the last fetch for the
submodule come from a "git fetch --recurse-submodules" subprocess
that is spawned via the fetch_multiple() interface for the remotes,
and the last fetch comes from the code at the end.

Because recursive fetching from submodules is done in each fetch for
the top-level in fetch_multiple(), the last fetch in the submodule
is redundant.  It only matters when fetch_one() interacts with a
single remote at the top-level.

While we are at it, there is one optimization that exists in dealing
with a group of remote, but is missing when "--all" is used.  In the
former, when the group turns out to be a group of one, instead of
spawning "git fetch" as a subprocess via the fetch_multiple()
interface, we use the normal fetch_one() code path.  Do the same
when handing "--all", if it turns out that we have only one remote
defined.

Reviewed-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: limit shared symref check only for local branches

This check was introduced in 8ee5d73137f (Fix fetch/pull when run without
--update-head-ok, 2008-10-13) in order to protect against replacing the ref
of the active branch by mistake, for example by running git fetch origin
master:master.

It was later extended in 8bc1f39f411 (fetch: protect branches checked out
in all worktrees, 2021-12-01) to scan all worktrees.

This operation is very expensive (takes about 30s in my repository) when
there are many tags or branches, and it is executed on every fetch, even if
no local heads are updated at all.

Limit it to protect only refs/heads/* to improve fetch performance.

Signed-off-by: Orgad Shaneh <orgads@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch-pack: make unexpected peek result non-fatal

When a Git server responds to a fetch request, it may send optional
sections before the packfile section. To handle this, the Git client
calls packet_reader_peek() (see process_section_header()) in order to
see what's next without consuming the line.

However, as implemented, Git errors out whenever what's peeked is not an
ordinary line. This is not only unexpected (here, we only need to know
whether the upcoming line is the section header we want) but causes
errors to include the name of a section header that is irrelevant to the
cause of the error. For example, at $DAYJOB, we have seen "fatal: error
reading section header 'shallow-info'" error messages when none of the
repositories involved are shallow.

Therefore, fix this so that the peek returns 1 if the upcoming line is
the wanted section header and nothing else. Because of this change,
reader->line may now be NULL later in the function, so update the error
message printing code accordingly.

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

MyFirstContribution: drop PR description for GGG single-patch contributions

By default, GitHub prefills the PR description using the commit message
for single-commit PRs. This results in a duplicate commit message below
the three-dash line if the contributor does not empty out the PR
description before submitting, which adds noise for reviewers.

Add a note to that effect in MyFirstContribution.txt.

This partly addresses:
https://github.com/gitgitgadget/gitgitgadget/issues/340

Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

MyFirstContribution: reference "The cover letter" in GitGitGadget section

The "Sending Patches via GitGitGadget" section mentions that the PR
title and description will be used as the cover letter, but does not
explain what is a cover letter or what should be included in it.

Refer readers to the new "The cover letter" section added in a previous
commit.

Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

MyFirstContribution: reference "The cover letter" in "Preparing Email"

The previous commit added a standalone section on the purpose of the
cover letter, drawing inspiration from the existing content of the
"Preparing Email" section.

Adjust "Preparing Email" to reference "The cover letter", to avoid
content duplication.

Also, use the imperative mode for the cover letter subject, as is done
in "The cover letter".

Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

MyFirstContribution: add standalone section on cover letter

An explanation of the purpose of the cover letter is included in the
"Sending Patches with git send-email" / "Preparing Email" section but is
missing from the "Sending Patches via GitGitGadget" section.

Add a standalone section "The cover letter" under the "Getting Started:
Anatomy of a Patch Series" header to explain what the cover letter is
used for and to draft the cover letter of the 'psuh' topic used in the
tutorial.

For now we mostly copy content from the "Sending Patches with git
send-email" section but do not adjust that section, nor the GGG section,
to reference the new section. This is done in following commits.

Also, adjust the "Preparing Email" Asciidoc anchor to avoid conflicts.

Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

MyFirstContribution: add "Anatomy of a Patch Series" section

Before describing how to send patches to the mailing list either with
GitGitGadget or 'git send-email', the MyFirstContribution tutorial
includes a small "Getting Ready to Share" section where the two
different methods are briefly introduced.

Use this section to also describe what a patch series looks like once
submitted, so that readers get an understanding of the end result before
diving into how to accomplish that end result.

Start by copying the "thread overview" section of a recent contribution
from the public-inbox web UI and explaining how each commit is a
separate mail, and point out the cover letter.

Subsequent commits will move the existing description of the purpose of
the cover letter from the 'git send-email' section to this "anatomy"
section.

Also, change the wording in the introductory paragraph to use
"contributions" instead of "patches", since this makes more sense when
talking about GitHub pull requests.

Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit: fix "author_ident" leak

Since 4c28e4ada03 (commit: die before asking to edit the log
message, 2010-12-20), we have been "leaking" the "author_ident" when
prepare_to_commit() fails.  Instead of returning from right there,
introduce an exit status variable and jump to the clean-up label
at the end.

Instead of explicitly releasing the resource with strbuf_release(),
mark the variable with UNLEAK() at the end, together with two other
variables that are already marked as such.  If this were in a
utility function that is called number of times, but these are
different, we should explicitly release resources that grow
proportionally to the size of the problem being solved, but
cmd_commit() is like main() and there is no point in spending extra
cycles to release individual pieces of resource at the end, just
before process exit will clean everything for us for free anyway.

This fixes a leak demonstrated by e.g. "t3505-cherry-pick-empty.sh",
but unfortunately we cannot mark it or other affected tests as passing
now with "TEST_PASSES_SANITIZE_LEAK=true" as we'll need to fix many
other memory leaks before doing so.

Incidentally there are two tests that always passes the leak checker
with or without this change.  Mark them as such.

This is based on an earlier patch by Ævar, but takes a different
approach that is more maintainable.

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

ci: use https, not http to download binaries from perforce.com

Since 522354d70f4 (Add Travis CI support, 2015-11-27) the CI has used
http://filehost.perforce.com/perforce/ to download binaries from
filehost.perforce.com, they were then moved to this script in
657343a602e (travis-ci: move Travis CI code into dedicated scripts,
2017-09-10).

Let's use https instead for good measure. I don't think we need to
worry about the DNS or network between the GitHub CI and perforce.com
being MitM'd, but using https gives us extra validation of the payload
at least, and is one less thing to worry about when checking where
else we rely on non-TLS'd http connections.

Also, use the same download site at perforce.com for Linux and macOS
tarballs for consistency.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ci: reintroduce prevention from perforce being quarantined in macOS

5ed9fc3fc86 (ci: prevent `perforce` from being quarantined, 2020-02-27)
introduces this prevention for brew, but brew has been removed in a
previous commit, so reintroduce an equivalent option to avoid a possible
regression.

This doesn't affect github actions (as configure now) and is therefore
done silently to avoid any possible scary irrelevant messages.

Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ci: avoid brew for installing perforce

Perfoce's cask in brew is meant[1] to be used only by humans, so replace
its use from the CI with a scripted binary download which is less likely
to fail, as it is done in Linux.

Kept the logic together so it will be less likely to break when moved
around as on the fly code changes in this area are settled, at which
point it will also feasable to ammend it to avoid some of the hardcoded
values by using similar variables to the ones Linux does.

In that same line, a POSIX sh syntax is used instead of the similar one
used in Linux in preparation for an unrelated future change that might
change the shell currently configured for it.

This change reintroduces the risk that the installed binaries might not
work because of being quarantined that was fixed with 5ed9fc3fc86 (ci:
prevent `perforce` from being quarantined, 2020-02-27) but fixing that
now was also punted for simplicity and since the affected cloud provider
is scheduled to be retired with an on the fly change, but should be
addressed if that other change is not integrated further.

The discussion on the need to keep 2 radically different versions of
the binaries to be tested with Linux vs macOS or how to upgrade to
newer versions now that brew won't do that automatically for us has
been punted for now as well.  On that line the now obsolete comment
about it in lib.sh was originally being updated by this change but
created conflicts as it is moved around by other on the fly changes,
so will be addressed independently as well.

[1] https://github.com/Homebrew/homebrew-cask/pull/122347#discussion_r856026584

Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ci: make failure to find perforce more user friendly

In preparation for a future change that will make perforce installation
optional in macOS, make sure that the check for it is done without
triggering scary looking errors and add a user friendly message instead.

All other existing uses of 'type <cmd>' in our shell scripts that
check the availability of a command <cmd> send both standard output
and error stream to /dev/null to squelch "<cmd> not found" diagnostic
output, but this script left the standard error stream shown.

Redirect it just like everybody else to squelch this error message that
we fully expect to see.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit-graph.c: don't assume that stat() succeeds

Fix code added in 8d84097f965 (commit-graph: expire commit-graph
files, 2019-06-18) to check the return value of the stat() system
call. Not doing so caused us to use uninitialized memory in the "Bloom
generation is limited by --max-new-filters" test in
t4216-log-bloom.sh:

+ rm -f trace.event
+ pwd
+ GIT_TRACE2_EVENT=[...]/t/trash directory.t4216-log-bloom/limits/trace.event git commit-graph write --reachable --split=replace --changed-paths --max-new-filters=2
==24835== Syscall param utimensat(times[0].tv_sec) points to uninitialised byte(s)
==24835==    at 0x499E65A: __utimensat64_helper (utimensat.c:34)
==24835==    by 0x4999142: utime (utime.c:36)
==24835==    by 0x552BE0: mark_commit_graphs (commit-graph.c:2213)
==24835==    by 0x550822: write_commit_graph (commit-graph.c:2424)
==24835==    by 0x54E3A0: write_commit_graph_reachable (commit-graph.c:1681)
==24835==    by 0x4374BB: graph_write (commit-graph.c:269)
==24835==    by 0x436F7D: cmd_commit_graph (commit-graph.c:326)
==24835==    by 0x407B9A: run_builtin (git.c:465)
==24835==    by 0x406651: handle_builtin (git.c:719)
==24835==    by 0x407575: run_argv (git.c:786)
==24835==    by 0x406410: cmd_main (git.c:917)
==24835==    by 0x511F09: main (common-main.c:56)
==24835==  Address 0x1ffeffde70 is on thread 1's stack
==24835==  in frame #1, created by utime (utime.c:25)
==24835==  Uninitialised value was created by a stack allocation
==24835==    at 0x552B50: mark_commit_graphs (commit-graph.c:2201)
==24835==
[...]
error: last command exited with $?=126
not ok 137 - Bloom generation is limited by --max-new-filters

This would happen as we stat'd the non-existing
".git/objects/info/commit-graph" file. Let's fix mark_commit_graphs()
to check the stat()'s return value, and while we're at it fix another
case added in the same commit to do the same.

The caller in expire_commit_graphs() would have been less likely to
run into this, as it's operating on files it just got from readdir(),
but it could still happen due to a race with e.g. a concurrent "rm
-rf" of the commit-graph files.

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

object-file: fix a unpack_loose_header() regression in 3b6a8db3b03

Fix a regression in my 3b6a8db3b03 (object-file.c: use "enum" return
type for unpack_loose_header(), 2021-10-01) revealed both by running
the test suite with --valgrind, and with the amended "git fsck" test.

In practice this regression in v2.34.0 caused us to claim that we
couldn't parse the header, as opposed to not being able to unpack
it. Before the change in the C code the test_cmp added here would emit:

-error: unable to unpack header of ./objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391
+error: unable to parse header of ./objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391

I.e. we'd proceed to call parse_loose_header() on the uninitialized
"hdr" value, and it would have been very unlikely for that
uninitialized memory to be a valid git object.

The other callers of unpack_loose_header() were already checking the
enum values exhaustively. See 3b6a8db3b03 and
5848fb11acd (object-file.c: return ULHR_TOO_LONG on "header too long",
2021-10-01).

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

log test: skip a failing mkstemp() test under valgrind

Skip a test added in f1e3df31699 (t: increase test coverage of
signature verification output, 2020-03-04) when running under
valgrind. Due to valgrind's interception of mkstemp() this test will
fail with:

+ pwd
+ TMPDIR=[...]/t/trash directory.t4202-log/bogus git log --show-signature -n1 plain-fail
==7696== VG_(mkstemp): failed to create temp file: [...]/t/trash directory.t4202-log/bogus/valgrind_proc_7696_cmdline_d545ddcf
[... 10 more similar lines omitted ..]
valgrind: Startup or configuration error:
valgrind:    Can't create client cmdline file in [...]/t/trash directory.t4202-log/bogus/valgrind_proc_7696_cmdline_6e542d1d
valgrind: Unable to start up properly.  Giving up.
error: last command exited with $?=1

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

tests: using custom GIT_EXEC_PATH breaks --valgrind tests

Fix a regression in b7d11a0f5d2 (tests: exercise the RUNTIME_PREFIX
feature, 2021-07-24) where tests that want to set up and test a "git"
wrapper in $PATH conflicted with the t/bin/valgrind wrapper(s) doing
the same.

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

archive: do not let on-disk mode leak to zip archives

When the "--add-file" option is used to add the contents from an
untracked file to the archive, the permission mode bits for these
files are sent to the archive-backend specific "write_entry()"
method as-is.  We normalize the mode bits for tracked files way
before we pass them to the write_entry() method; we should do the
same here.

This is not strictly needed for "tar" archive-backend, as it has its
own code to further clean them up, but "zip" archive-backend is not
so well prepared.

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

pull: do not let submodule.recurse override fetch.recurseSubmodules

Fix a bug in "git pull" where `submodule.recurse` is preferred over
`fetch.recurseSubmodules` when performing a fetch
(Documentation/config/fetch.txt says that `fetch.recurseSubmodules`
should be preferred.). Do this by passing the value of the
"--recurse-submodules" CLI option to the underlying fetch, instead of
passing a value that combines the CLI option and config variables.

In other words, this bug occurred because builtin/pull.c is conflating
two similar-sounding, but different concepts:

- Whether "git pull" itself should care about submodules e.g. whether it
  should update the submodule worktrees after performing a merge.
- The value of "--recurse-submodules" to pass to the underlying "git
  fetch".

Thus, when `submodule.recurse` is set, the underlying "git fetch" gets
invoked with "--recurse-submodules[=value]", overriding the value of
`fetch.recurseSubmodules`.

An alternative (and more obvious) approach to fix the bug would be to
teach "git pull" to understand `fetch.recurseSubmodules`, but the
proposed solution works better because:

- We don't maintain two identical config-parsing implementions in "git
  pull" and "git fetch".
- It works better with other commands invoked by "git pull" e.g. "git
  merge" won't accidentally respect `fetch.recurseSubmodules`.

Reported-by: Huang Zou <huang.zou@schrodinger.com>
Helped-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

second 0th batch of topics from the previous cycle

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

Merge branch 'rs/commit-summary-wo-break-rewrite'

The commit summary shown after making a commit is matched to what
is given in "git status" not to use the break-rewrite heuristics.

* rs/commit-summary-wo-break-rewrite:
  commit, sequencer: turn off break_opt for commit summary

Merge branch 'pw/test-malloc-with-sanitize-address'

Avoid problems from interaction between malloc_check and address
sanitizer.

* pw/test-malloc-with-sanitize-address:
  tests: make SANITIZE=address imply TEST_NO_MALLOC_CHECK

Merge branch 'ea/rebase-code-simplify'

Code clean-up.

* ea/rebase-code-simplify:
  rebase: simplify an assignment of options.type in cmd_rebase

Merge branch 'kt/commit-graph-plug-fp-leak-on-error'

Fix a leak of FILE * in an error codepath.

* kt/commit-graph-plug-fp-leak-on-error:
  commit-graph: close file before returning NULL

Merge branch 'ah/rebase-keep-base-fix'

"git rebase --keep-base <upstream> <branch-to-rebase>" computed the
commit to rebase onto incorrectly, which has been corrected.

* ah/rebase-keep-base-fix:
  rebase: use correct base for --keep-base when a branch is given

bisect: output bisect setup status in bisect log

This allows seeing the current intermediate status without adding a new
good or bad commit:

    $ git bisect log | tail -1
    # status: waiting for bad commit, 1 good commit known

Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: output state before we are ready to compute bisection

Commit 73c6de06aff8 ("bisect: don't use invalid oid as rev when
starting") changes the behaviour of `git bisect` to consider invalid
oids as pathspecs again, as in the old shell implementation.

While that behaviour may be desirable, it can also cause confusion. For
example, while bisecting in a particular repo I encountered this:

    $ git bisect start d93ff48803f0 v6.3
    $

...which led to me sitting for a few moments, wondering why there's no
printout stating the first rev to check.

It turns out that the tag was actually "6.3", not "v6.3", and thus the
bisect was still silently started with only a bad rev, because
d93ff48803f0 was a valid oid and "v6.3" was silently considered to be a
pathspec.

While this behaviour may be desirable, it can be confusing, especially
with different repo conventions either using or not using "v" before
release names, or when a branch name or tag is simply misspelled on the
command line.

In order to avoid situations like this, make it more clear what we're
waiting for:

    $ git bisect start d93ff48803f0 v6.3
    status: waiting for good commit(s), bad commit known

We already have good output once the bisect process has begun in
earnest, so we don't need to do anything more there.

Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of git://git.ozlabs.org/~paulus/gitk

* 'master' of git://git.ozlabs.org/~paulus/gitk:
  gitk: include y coord in recorded sash position
  gitk: trivial indentation fix

SubmittingPatches: use more stable git.ozlabs.org URL

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

gitk: include y coord in recorded sash position

6cd80496e9 ("gitk: Resize panes correctly when reducing window size",
2020-10-03) introduces a mechanism to record previously-set sash
positions to make sure that correct values are used while computing
resize proportions. However, if we are not using ttk, then sash
represents only the x coordinate and the recorded sash (`oldsash`) only
includes the x coordinate. When we need to access the y coordinate via
the recorded sash position, we generate the following Application Error
popup:

Error: expected integer but got ""

expected integer but got ""

expected integer but got ""

     while executing

"$win sash place 0 $sash0 [lindex $s0 1]"

     (procedure "resizeclistpanes" line 38)

     invoked from within

"resizeclistpanes .tf.histframe.pwclist 2818"

     (command bound to event)

To fix this, if we are not using ttk, we append the sash positions with
the y coordinates before recording them to match the use_ttk case.

Signed-off-by: Halil Sen <halil.sen@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>

gitk: trivial indentation fix

No functional changes.

Signed-off-by: Halil Sen <halil.sen@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>

0th batch for topics from the previous cycle

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

Merge branch 'ea/progress-partial-blame'

The progress meter of "git blame" was showing incorrect numbers
when processing only parts of the file.

* ea/progress-partial-blame:
  blame: report correct number of lines in progress when using ranges

Merge branch 'fr/vimdiff-layout'

Reimplement "vimdiff[123]" mergetool drivers with a more generic
layout mechanism.

* fr/vimdiff-layout:
  mergetools: add description to all diff/merge tools
  vimdiff: add tool documentation
  vimdiff: integrate layout tests in the unit tests framework ('t' folder)
  vimdiff: new implementation with layout support

Merge branch 'jh/p4-various-fixups'

Various cleanups to "git p4".

* jh/p4-various-fixups: (22 commits)
  git-p4: sort imports
  git-p4: seperate multiple statements onto seperate lines
  git-p4: move inline comments to line above
  git-p4: only seperate code blocks by a single empty line
  git-p4: compare to singletons with "is" and "is not"
  git-p4: normalize indentation of lines in conditionals
  git-p4: ensure there is a single space around all operators
  git-p4: ensure every comment has a single #
  git-p4: remove spaces between dictionary keys and colons
  git-p4: remove redundant backslash-continuations inside brackets
  git-p4: remove extraneous spaces before function arguments
  git-p4: place a single space after every comma
  git-p4: removed brackets when assigning multiple return values
  git-p4: remove spaces around default arguments
  git-p4: remove padding from lists, tuples and function arguments
  git-p4: sort and de-duplcate pylint disable list
  git-p4: remove commented code
  git-p4: convert descriptive class and function comments into docstrings
  git-p4: improve consistency of docstring formatting
  git-p4: indent with 4-spaces
  ...

Merge branch 'tk/untracked-cache-with-uall'

The performance of the "untracked cache" feature has been improved
when "--untracked-files=<mode>" and "status.showUntrackedFiles"
are combined.

* tk/untracked-cache-with-uall:
  untracked-cache: support '--untracked-files=all' if configured
  untracked-cache: test untracked-cache-bypassing behavior with -uall

Merge branch 'ab/misc-cleanup'

Code clean-up.

* ab/misc-cleanup:
  alloc.[ch]: remove alloc_report() function
  object-store.h: remove unused has_sha1_file*()
  pack-bitmap-write: remove unused bitmap_reset() function
  xdiff/xmacros.h: remove unused XDL_PTRFREE
  configure.ac: remove USE_PIC comment
  run-command.h: remove always unused "clean_on_exit_handler_cbdata"

unpack-trees: preserve index sparsity

When unpacking trees, set the default sparsity of the resultant index based
on repo settings and 'is_sparse_index_allowed()'.

Normally, when executing 'unpack_trees', the output index is marked sparse
when (and only when) it unpacks a sparse directory. However, an index may be
"sparse" even if it contains no sparse directories - when all files fall
inside the sparse-checkout definition or otherwise have SKIP_WORKTREE
disabled. Therefore, the output index may be marked "full" even when it is
"sparse", resulting in unnecessary 'ensure_full_index' calls when writing to
disk. Avoid this by setting the "default" index sparsity to match what is
expected for the repository.

As a consequence of this fix, the (non-merge) 'read-tree' performed when
applying a stash with untracked files no longer expands the index. Update
the corresponding test in 't1092'.

Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

stash: apply stash using 'merge_ort_nonrecursive()'

Update 'stash' to use 'merge_ort_nonrecursive()' to apply a stash to the
current working tree. When 'git stash apply' was converted from its shell
script implementation to a builtin in 8a0fc8d19d (stash: convert apply to
builtin, 2019-02-25), 'merge_recursive_generic()' was used to merge a stash
into the working tree as part of 'git stash (apply|pop)'. However, with the
single merge base used in 'do_apply_stash()', the commit wrapping done by
'merge_recursive_generic()' is not only unnecessary, but misleading (the
*real* merge base is labeled "constructed merge base"). Therefore, a
non-recursive merge of the working tree, stashed tree, and stash base tree
is more appropriate.

There are two options for a non-recursive merge-then-update-worktree
function: 'merge_trees()' and 'merge_ort_nonrecursive()'. Use
'merge_ort_nonrecursive()' to align with the default merge strategy used by
'git merge' (6a5fb96672 (Change default merge backend from recursive to ort,
2021-08-04)) and, because merge-ort does not operate in-place on the index,
avoid unnecessary index expansion. Update tests in 't1092' verifying index
expansion for 'git stash' accordingly.

Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

read-cache: set sparsity when index is new

When the index read in 'do_read_index()' does not exist on-disk, mark the
index "sparse" if the executing command does not require a full index and
sparse index is otherwise enabled.

Some commands (such as 'git stash -u') implicitly create a new index (when
the 'GIT_INDEX_FILE' variable points to a non-existent file) and perform
some operation on it. However, when this index is created, it isn't created
with the same sparsity settings as the repo index. As a result, while these
indexes may be sparse during the operation, they are always expanded before
being written to disk. We can avoid that expansion by defaulting the index
to "sparse", in which case it will only be expanded if the full index is
needed.

Note that the function 'set_new_index_sparsity()' is created despite having
only a single caller because additional callers will be added in a
subsequent patch.

Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sparse-index: expose 'is_sparse_index_allowed()'

Expose 'is_sparse_index_allowed()' publicly so that it may be used by
callers outside of 'sparse-index.c'. While no such callers exist yet, it
will be used in a subsequent commit.

Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

stash: integrate with sparse index

Enable sparse index in 'git stash' by disabling
'command_requires_full_index'.

With sparse index enabled, some subcommands of 'stash' work without
expanding the index, e.g., 'git stash', 'git stash list', 'git stash drop',
etc. Others ensure the index is expanded either directly (as in the case of
'git stash [pop|apply]', where the call to 'merge_recursive_generic()' in
'do_apply_stash()' triggers the expansion), or in a command called
internally by stash (e.g., 'git update-index' in 'git stash -u'). So, in
addition to enabling sparse index, add tests to 't1092' demonstrating which
variants of 'git stash' expand the index, and which do not.

Finally, add the option to skip writing 'untracked.txt' in
'ensure_not_expanded', and use that option to successfully apply stashed
untracked files without a conflict in 'untracked.txt'.

Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

stash: expand sparse-checkout compatibility testing

Add tests verifying expected 'git stash' behavior in
't1092-sparse-checkout-compatibility'. These cases establish the expected
behavior of 'git stash' in a sparse-checkout and verify consistency both
with and without a sparse index. Although no sparse index compatibility has
been integrated into 'git stash' yet, the tests are all 'expect_success' -
we don't want the cone-mode sparse-checkout behavior to change depending on
whether it is using a sparse index or not. Therefore, we expect these tests
to continue passing once sparse index is integrated with 'git stash'.

Additionally, add performance test cases for 'git stash' both with and
without untracked files. Note that, unlike the other tests in
'p2000-sparse-operations.sh', the tests added for 'stash' are combination
operations. This is done to ensure the stash/unstash is not blocked by the
modification of '$SPARSE_CONE/a' performed as part of 'test_perf_on_all'.

Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

detect-compiler: make detection independent of locale

`detect-compiler` has accumulated a few compiler dependent workarounds
lately for the more and more ubiquitious gcc12. This is intended to make
CI set-ups work across tool-chain updates, but also help those
developers who build with `DEVELOPER=1`.

Alas, `detect-compiler` uses the locale dependent output of `$(CC) -v`
to parse for the version string, which fails unless it literally
contains ` version`.

Use `LANG=C $(CC) -v` instead to grep for stable output.

Signed-off-by: Michael J Gruber <git@grubix.eu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Sync with v2.36.1

Git 2.36.1

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

Merge branch 'ab/cc-package-fixes' into maint

Correct choices of C compilers used in various CI jobs.
source: <patch-v3-1.1-8b3444ecc87-20220422T092015Z-avarab@gmail.com>

* ab/cc-package-fixes:
  CI: select CC based on CC_PACKAGE (again)

Merge branch 'jc/cocci-xstrdup-or-null-fix' into maint

Get rid of a bogus and over-eager coccinelle rule.
source: <xmqq1qxd6e4x.fsf@gitster.g>

* jc/cocci-xstrdup-or-null-fix:
  cocci: drop bogus xstrdup_or_null() rule

Merge branch 'rs/format-patch-pathspec-fix' into maint

"git format-patch <args> -- <pathspec>" lost the pathspec when
showing the second and subsequent commits, which has been
corrected.
source: <c36896a1-6247-123b-4fa3-b7eb24af1897@web.de>

* rs/format-patch-pathspec-fix:
  2.36 format-patch regression fix

Merge branch 'rs/fast-export-pathspec-fix' into maint

"git fast-export -- <pathspec>" lost the pathspec when showing the
second and subsequent commits, which has been corrected.
source: <2c988c7b-0efe-4222-4a43-8124fe1a9da6@web.de>

* rs/fast-export-pathspec-fix:
  2.36 fast-export regression fix

Merge branch 'jc/show-pathspec-fix' into maint

"git show <commit1> <commit2>... -- <pathspec>" lost the pathspec
when showing the second and subsequent commits, which has been
corrected.
source: <xmqqo80j87g0.fsf_-_@gitster.g>

* jc/show-pathspec-fix:
  2.36 show regression fix

Merge branch 'rs/name-rev-fix-free-after-use' into maint

Regression fix for 2.36 where "git name-rev" started to sometimes
reference strings after they are freed.

This fixes a regression in 2.36 and is slate to go to 2.36.1
source: <340c8810-d912-7b18-d46e-a9d43f20216a@web.de>

* rs/name-rev-fix-free-after-use:
  Revert "name-rev: release unused name strings"

Merge branch 'jc/diff-tree-stdin-fix' into maint

"diff-tree --stdin" has been broken for about a year, but 2.36
release broke it even worse by breaking running the command with
<pathspec>, which in turn broke "gitk" and got noticed.  This has
been corrected by aligning its behaviour to that of "log".

This fixes a regression in 2.36 and is slate to go to 2.36.1
source: <xmqq7d7bsu2n.fsf@gitster.g>

* jc/diff-tree-stdin-fix:
  2.36 gitk/diff-tree --stdin regression fix

Merge branch 'gc/submodule-update-part2' into maint

"git submodule update" without pathspec should silently skip an
uninitialized submodule, but it started to become noisy by mistake.

This fixes a regression in 2.36 and is slate to go to 2.36.1
source: <pull.1258.v2.git.git.1650890741430.gitgitgadget@gmail.com>

* gc/submodule-update-part2:
  submodule--helper: fix initialization of warn_if_uninitialized

trace2 docs: add missing full stop

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

trace2 docs: clarify what `varargs` is all about

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

trace2 docs: fix a JSON formatted example

The example was not in valid JSON format due to a duplicate key "sid".

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

trace2 docs: surround more terms in backticks

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

trace2 docs: "printf" is not an English word

We append an ellipsis and enclose it in backticks to indicate that it is
a function elsewhere, let's also use that here.

While at it, ensure the same for `waitpid()`.

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

trace2 docs: a couple of grammar fixes

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