Merge branch 'jk/tests-timestamp-fix' into master

The test framework has been updated so that most tests will run
with predictable (artificial) timestamps.

* jk/tests-timestamp-fix:
  t9100: stop depending on commit timestamps
  test-lib: set deterministic default author/committer date
  t9100: explicitly unset GIT_COMMITTER_DATE
  t5539: make timestamp requirements more explicit
  t9700: loosen ident timezone regex
  t6000: use test_tick consistently

Merge branch 'ds/commit-graph-bloom-updates' into master

Updates to the changed-paths bloom filter.

* ds/commit-graph-bloom-updates:
  commit-graph: check all leading directories in changed path Bloom filters
  revision: empty pathspecs should not use Bloom filters
  revision.c: fix whitespace
  commit-graph: check chunk sizes after writing
  commit-graph: simplify chunk writes into loop
  commit-graph: unify the signatures of all write_graph_chunk_*() functions
  commit-graph: persist existence of changed-paths
  bloom: fix logic in get_bloom_filter()
  commit-graph: change test to die on parse, not load
  commit-graph: place bloom_settings in context

Merge branch 'sg/commit-graph-cleanups' into master

The changed-path Bloom filter is improved using ideas from an
independent implementation.

* sg/commit-graph-cleanups:
  commit-graph: simplify write_commit_graph_file() #2
  commit-graph: simplify write_commit_graph_file() #1
  commit-graph: simplify parse_commit_graph() #2
  commit-graph: simplify parse_commit_graph() #1
  commit-graph: clean up #includes
  diff.h: drop diff_tree_oid() & friends' return value
  commit-slab: add a function to deep free entries on the slab
  commit-graph-format.txt: all multi-byte numbers are in network byte order
  commit-graph: fix parsing the Chunk Lookup table
  tree-walk.c: don't match submodule entries for 'submod/anything'

fmt-merge-msg: allow merge destination to be omitted again

In Git 2.28, we stopped special casing 'master' when producing the
default merge message by just removing the code to squelch "into
'master'" at the end of the message.

Introduce multi-valued merge.suppressDest configuration variable
that gives a set of globs to match against the name of the branch
into which the merge is being made, to let users specify for which
branch fmt-merge-msg's output should be shortened.  When it is not
set, 'master' is used as the sole value of the variable by default.

The above move mostly reverts the pre-2.28 default in repositories
that have no relevant configuration.

Add a few tests to protect the behaviour with the new configuration
variable from future regression.

Helped-by: Linus Torvalds <redacted>
Helped-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Revert "fmt-merge-msg: stop treating `master` specially"

This reverts commit 489947cee5095b168cbac111ff7bd1eadbbd90dd, which
stopped treating merges into the 'master' branch as special when
preparing the default merge message.  As the goal was not to have
any single branch designated as special, it solved it by leaving the
"into <branchname>" at the end of the title of the default merge
message for any and all branches.  An obvious and easy alternative
to treat everybody equally could have been to remove it for every
branch, but that involves loss of information.

We'll introduce a new mechanism to let end-users specify merges into
which branches would omit the "into <branchname>" from the title of
the default merge message, and make the mechanism, when unconfigured,
treat the traditional 'master' special again, so all the changes to
the tests we made earlier will become unnecessary, as these tests
will be run without configuring the said new mechanism.

Signed-off-by: Junio C Hamano <redacted>

t: remove test_oid_init in tests

Now that we call test_oid_init in the setup for all test scripts,
there's no point in calling it individually.  Remove all of the places
where we've done so to help keep tests tidy.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

docs: add documentation for extensions.objectFormat

Document the extensions.objectFormat config setting.  Warn users not to
modify it themselves.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

ci: run tests with SHA-256

Now that we have Git supporting SHA-256, we'd like to make sure that we
don't regress that state.  Unfortunately, it's easy to do so, so to
help, let's add code to run one of our CI jobs with SHA-256 as the
default hash.  This will help us detect any problems that may occur.

We pick the linux-clang job because it's relatively fast and the
linux-gcc job already runs the testsuite twice.  We want our tests to
run as fast as possible, so we wouldn't want to add a third run to the
linux-gcc job.  To make sure we properly exercise the code, let's run
the tests in the default mode (SHA-1) first and then run a second time
with SHA-256.  We explicitly specify SHA-1 for the first run so that if
we change the default in the future, we make sure to test both cases.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t: make SHA1 prerequisite depend on default hash

Currently, the SHA1 prerequisite depends on the output of git
hash-object.  However, in order for that to produce sane behavior, we
must be in a repository.  If we are not, the default will remain SHA-1,
and we'll produce wrong results if we're using SHA-256 for the testsuite
but the test assertion starts when we're not in a repository.

Check the environment variable we use for this purpose, leaving it to
default to SHA-1 if none is specified.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t: allow testing different hash algorithms via environment

To allow developers to run the testsuite with a different algorithm than
the default, provide an environment variable, GIT_TEST_DEFAULT_HASH, to
specify the algorithm to use. Compute the fixed constants using
test_oid. Move the constant initialization down below the point where
test-lib-functions.sh is loaded so the functions are defined.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t: add test_oid option to select hash algorithm

In some tests, we have data files which are written with a particular
hash algorithm. Instead of keeping two copies of the test files, we can
keep one, and translate the value on the fly.

In order to do so, we'll need to read both the source algorithm and the
current algorithm, so add an optional flag to the test_oid helper that
lets us look up a value for a specified hash algorithm. This should
not cause any conflicts with existing tests, since key arguments to
test_oid are allowed to contains only shell identifier characters.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

repository: enable SHA-256 support by default

Now that we have a complete SHA-256 implementation in Git, let's enable
it so people can use it.  Remove the ENABLE_SHA256 define constant
everywhere it's used.  Add tests for initializing a repository with
SHA-256.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

setup: add support for reading extensions.objectformat

The transition plan specifies extensions.objectFormat as the indication
that we're using a given hash in a certain repo.  Read this as one of
the extensions we support.  If the user has specified an invalid value,
fail.

Ensure that we reject the extension if the repository format version is
0.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

bundle: add new version for use with SHA-256

Currently we detect the hash algorithm in use by the length of the
object ID.  This is inelegant and prevents us from using a different
hash algorithm that is also 256 bits in length.

Since we cannot extend the v2 format in a backward-compatible way, let's
add a v3 format, which is identical, except for the addition of
capabilities, which are prefixed by an at sign.  We add "object-format"
as the only capability and reject unknown capabilities, since we do not
have a network connection and therefore cannot negotiate with the other
side.

For compatibility, default to the v2 format for SHA-1 and require v3
for SHA-256.

In t5510, always use format v3 so we can be sure we produce consistent
results across hash algorithms.  Since head -n N lists the top N lines
instead of the Nth line, let's run our output through sed to normalize
it and compare it against a fixed value, which will make sure we get
exactly what we're expecting.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

builtin/verify-pack: implement an --object-format option

A recently added test in t5702 started using git verify-pack outside of
a repository.  While this poses no problems with SHA-1, with SHA-256 we
implicitly rely on the setup of the repository to initialize our hash
algorithm settings.

Since we're not in a repository here, we need to provide git verify-pack
help to set things up properly.  git index-pack already knows an
--object-format option, so let's accept one as well and pass it down to
our git index-pack invocation.  Since we're now dynamically adjusting
the elements in argv, let's switch to using struct argv_array to manage
them.  Finally, let's make t5702 pass the proper argument on down to its
git verify-pack caller.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

http-fetch: set up git directory before parsing pack hashes

In dd4b732df7 ("upload-pack: send part of packfile response as uri",
2020-06-10), the git http-fetch code learned how to take  ac --packfile
option.  This option takes an argument, which is the name of a packfile
hash, and parses it using parse_oid_hex.  It does so before calling
setup_git_directory.

However, in a SHA-256 repository this fails to work, since we have not
set the hash algorithm in use and parse_oid_hex fails as a consequence.
To ensure that we can parse packfile hashes of the right length, let's
set up the git directory before we start parsing arguments.

Since we still want to allow the invocation of -h to print the help when
we're not in a repository, gracefully handle us being outside of one and
produce an error after argument parsing has finished.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t0410: mark test with SHA1 prerequisite

These tests try to check that we behave properly if we encounter a
repository with version 0 but an extension.  This is a laudable goal,
but the test cannot work with SHA-256, since SHA-256 repositories always
have an existing extension and are never version 0.

Add a SHA1 prerequisite to these tests.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5308: make test work with SHA-256

This test needs multiple object IDs that have the same first byte.
Update the pack test code to generate a suitable packed value for
SHA-256.  Update the test to use this value when using SHA-256.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9700: make hash size independent

The Perl test script for t9700 was matching on exactly 40 hex
characters.  With SHA-256, we'll have 64 hex-character object IDs.
Create a variable with a regex which matches exactly 40 or 64 hex
characters and use that to match the output.  Note that both of the uses
of this can be anchored, which makes the code simpler, so do that as
well.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9500: ensure that algorithm info is preserved in config

When we use a hash algorithm other than SHA-1, it's important to
preserve the hash-related values in the config file, but this test
overwrites the config file with a new one. Ensure we copy these values
properly from the old config to the new one so that the repository can
be read if it's using SHA-256.

Note that if there is no extensions.objectFormat value set, git config
will return unsuccessfully if we try to read it; since this is not an
error for us, use test_might_fail.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9350: make hash size independent

This test checks for several commit object sizes to verify that objects
are encoded as expected. However, the size of a commit object differs
between SHA-1 and SHA-256, since each contains a hex representation of
the tree's object ID. Since these are root commits, compute the size of
each commit by using a constant plus the size of a single hex object ID.

In addition, use $ZERO_OID instead of a hard-coded object ID.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9301: make hash size independent

Instead of using a hard-coded all-zeros object ID, use $ZERO_OID.
Compute the length of the object IDs in use and use this instead of
hard-coding the constant 40.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9300: use $ZERO_OID instead of hard-coded object ID

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9300: abstract away SHA-1-specific constants

Adjust the test so that it computes variables for object IDs instead of
using hard-coded hashes.  In addition, use cut to filter out the object
IDs and verify only the information that we're really interested in.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t8011: make hash size independent

Allow lines which start with either a 40- or 64-character hex object ID,
to allow for both SHA-1 and SHA-256.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t8003: make hash size independent

One assertion in this test invokes git with core.abbrev set to "40".
Since we're expecting the full hash length, use test_oid to look up the
full hash length for the hash in use.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t8002: make hash size independent

Compute the length of an object ID instead of hard-coding 40-based
values.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t7508: use $ZERO_OID instead of hard-coded constant

Use the ZERO_OID variable to abbreviate the all-zeros object ID for
maintainability and to avoid depending on a specific size for the hash.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t7506: avoid checking for SHA-1-specific constants

Adjust the test to sanitize the diffs and strip out object IDs from
them, as it does for other object IDs, since we are not interested in
the particular values used.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t7405: make hash size independent

Use $ZERO_OID instead of hard-coding a fixed size all-zeros object ID.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t7400: make hash size independent

Instead of using cut with hard-coded hash sizes, use cut with fields, or
where that's not possible, sed with $OID_REGEX, so that the tests are
independent of hash size.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t7102: abstract away SHA-1-specific constants

Adjust the test so that it computes variables for object IDs instead of
using hard-coded hashes.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t7201: abstract away SHA-1-specific constants

Adjust the test so that it computes variables for object IDs instead of
using hard-coded hashes.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t7063: make hash size independent

Use test_oid instead of hard-coding algorithm-specific constants and
all-zero values.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t7003: compute appropriate length constant

Instead of using a specific invalid hard-coded object ID, look one
up from the translation table.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t6501: avoid hard-coded objects

This test contains hard-coded invalid object IDs.  Make it hash size
independent by generating invalid object IDs using the translation
tables.  Add a setup target to ensure the output of test_oid_init is
checked properly.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t6500: specify test values for SHA-256

In this test, we want to produce several blobs whose first two hex
characters are "17", since we look at this object directory as a proxy
for how many loose objects there are before we need to GC.  Use
test_oid_cache to specify strings that will hash to the right values
when turned into blobs.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t6301: make hash size independent

Instead of hard-coding a fixed length example object ID in the test,
compute one using the translation tables.  Move a variable into the
setup block so that we can ensure the exit status of test_oid is
checked.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t6101: make hash size independent

Use $OID_REGEX instead of a hard-coded regular expression.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t6100: make hash size independent

Instead of hard-coding a constant 40, split the output of rev-list by
field.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t3404: prepare 'short SHA-1 collision' tests for SHA-256

The idea of the magic value "ac4f2ee" in this test is to make the
reworded commit `collide2` have the same shortened ID as the commit
`collide3`.

To port the same idea to the SHA-256 version of Git, we therefore need
another magic value that causes the same collision, but this time with
the SHA-256 version of the commit IDs.

In this patch, we add code guarded by `GIT_TEST_FIND_COLLIDER` to do
exactly that. Essentially, a large number of integers is appended to the
commit message "collide2" to find such a collision. To make it easier to
find such a collision, we reduce the number of digits to 4.

As the tests are no longer dependent on SHA-1, we also rename their
titles to talk about "commit IDs" instead of "SHA-1s".

Signed-off-by: Johannes Schindelin <redacted>
Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t3305: make hash agnostic

When computing the fanout length, let's use test_oid to look up the
hexadecimal size of the hash in question instead of hard-coding a value.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t1001: use $ZERO_OID

Use $ZERO_OID to make the test hash independent.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

t: make test-bloom initialize repository

The bloom filter code relies on reading object IDs using parse_oid_hex.
In order to make that work with an appropriate size, we need to have
initialized the repository's hash algorithm.  Since the values we're
processing depend on the repository in use, let's set up the repository
when we run the test helper.

Signed-off-by: brian m. carlson <redacted>
Reviewed-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

mergetools: add support for nvimdiff (neovim) family

Signed-off-by: pudinha <redacted>
Signed-off-by: Junio C Hamano <redacted>

mergetool--lib: improve support for vimdiff-style tool variants

The merge tools vimdiff2, vimdiff3, gvimdiff2, gvimdiff3 and bc3 are all
variants of the main tools vimdiff and bc. They are implemented in the
main and a one-liner script that just sources it exist for each.

Allow variants ending in [0-9] to be correctly wired without the need
for such one-liners, so instead of 5 scripts, only 1 (gvimdiff) is
needed.

Signed-off-by: pudinha <redacted>
Signed-off-by: Junio C Hamano <redacted>

doc/git-log: clarify handling of merge commit diffs

It can be surprising that git-log doesn't show any diff for merge
commits by default. Arguably "--cc" would be a reasonable default, but
it's very expensive (which is why we turn it on for "git show" but not
for "git log"). Let's at least document the current behavior, including
the recent "--first-parent implies -m" case

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

doc/git-log: move "-t" into diff-options list

The "-t" option is infrequently used; it doesn't deserve a spot near the
top of the options list. Let's push it down into the diff-options
include, near the definition of --raw.

We'll protect it with a git-log ifdef, since it doesn't make any sense
for non-tree diff commands. Note that this means it also shows up in
git-show, but that's a good thing; it applies equally well there.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

doc/git-log: drop "-r" diff option

This has been the default since 170c04383b (Porcelain level "log" family
should recurse when diffing., 2007-08-27). There's not even a way to
turn it off, so you'd never even want "-r" to override that.

It's not the default for plumbing like diff-tree, of course, but the
option is documented separately there.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

doc/git-log: move "Diff Formatting" from rev-list-options

Our rev-list-options.txt include has a "Diff Formatting" section, but it
is ifndef'd out for all manpages except git-log. And a few bits of the
text are rather out of date.

We say "some of these options are specific to git-rev-list". That's
obviously silly since we (even before this patch) show the content only
for git-log. But moreover, it's not true; each of the listed options is
meaningful for other diff commands.

We also say "...however other diff options may be given. See git-diff-files
for more options." But there's no need to do so; git-log already has a
"Common Diff Options" section which includes diff-options.txt.

So let's move these options over to git-log and put them with the other
diff options, giving a single "diff" section for the git-log
documentation. We'll call it "Diff Formatting" but use the all-caps
top-level header to match its sibling sections. And we'll rewrite the
section intro to remove the useless bits and give a more generic
overview of the section which can be later extended.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

log: enable "-m" automatically with "--first-parent"

When using "--first-parent" to consider history as a single line of
commits, git-log still defaults to treating merges specially, even
though they could be considered as single commits in the linearized
history (that just introduce all of the changes from the second and
higher parents).

Let's instead have "--first-parent" imply "-m", which makes something
like:

  git log --first-parent -p

do what you'd expect. Likewise:

  git log --first-parent -Sfoo

will find "foo" in merge commits.

No new test is needed; we'll tweak the output of the existing
"--first-parent -p" test, which now matches the "-m --first-parent -p"
test. The unchanged existing test for "--no-diff-merges" confirms that
the user can get the old behavior if they want.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

revision: add "--no-diff-merges" option to counteract "-m"

The "-m" option sets revs->ignore_merges to "0", but there's no way to
undo it. This probably isn't something anybody overly cares about, since
"1" is already the default, but it will serve as an escape hatch when we
flip the default for ignore_merges to "0" in more situations.

We'll also add a few extra niceties:

  - initialize the value to "-1" to indicate "not set", and then resolve
    it to the normal 0/1 bool in setup_revisions(). This lets any tweak
    functions, as well as setup_revisions() itself, avoid clobbering the
    user's preference (which until now they couldn't actually express).

  - since we now have --no-diff-merges, let's add the matching
    --diff-merges, which is just a synonym for "-m". Then we don't even
    need to document --no-diff-merges separately; it countermands the
    long form of "-m" in the usual way.

The new test shows that this behaves just the same as the current
behavior without "-m".

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

log: drop "--cc implies -m" logic

This was added by 82dee4160c (log: show merge commit when --cc is given,
2015-08-20), which explains why we need it. But that commit failed to
notice that setup_revisions() already does the same thing, since
cd2bdc5309 (Common option parsing for "git log --diff" and friends,
2006-04-14).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

comment: fix spelling mistakes inside comments

This commit fixes a couple of minor spelling mistakes inside
comments.

Signed-off-by: Steve Kemp <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-help.txt: fix mentions of option --guides

Fix typos introduced in commit a133737b80 ("doc: include --guide option
description for "git help"", 2013-04-02).

Signed-off-by: Andrei Rybak <redacted>
Signed-off-by: Junio C Hamano <redacted>

grep: avoid using oid_to_hex() with parse_object_or_die()

parse_object_or_die() is passed an object ID and a name to show if the
object cannot be parsed.  If the name is NULL then it shows the
hexadecimal object ID.  Use that feature instead of preparing and
passing the hexadecimal representation to the function proactively.
That's shorter and a bit more efficient.

Signed-off-by: René Scharfe <redacted>
Signed-off-by: Junio C Hamano <redacted>

strvec: drop argv_array compatibility layer

There are no callers which need it anymore. Any topics in flight will
need to be updated as they get merged in (but the compiler will make
that quite clear).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

strvec: update documention to avoid argv_array

There were a few mentions of argv_array in a non-code file which didn't
get picked up in the previous commits (note that even comments in code
files were already covered because of the mechanical conversion via
perl).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

strvec: fix indentation in renamed calls

Code which split an argv_array call across multiple lines, like:

  argv_array_pushl(&args, "one argument",
                   "another argument", "and more",
   NULL);

was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:

  strvec_pushl(&args, "one argument",
                   "another argument", "and more",
   NULL);

Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:

  git jump grep 'strvec_.*,$'

and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

strvec: convert remaining callers away from argv_array name

We eventually want to drop the argv_array name and just use strvec
consistently. There's no particular reason we have to do it all at once,
or care about interactions between converted and unconverted bits.
Because of our preprocessor compat layer, the names are interchangeable
to the compiler (so even a definition and declaration using different
names is OK).

This patch converts all of the remaining files, as the resulting diff is
reasonably sized.

The conversion was done purely mechanically with:

  git ls-files '*.c' '*.h' |
  xargs perl -i -pe '
    s/ARGV_ARRAY/STRVEC/g;
    s/argv_array/strvec/g;
  '

We'll deal with any indentation/style fallouts separately.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

strvec: convert more callers away from argv_array name

We eventually want to drop the argv_array name and just use strvec
consistently. There's no particular reason we have to do it all at once,
or care about interactions between converted and unconverted bits.
Because of our preprocessor compat layer, the names are interchangeable
to the compiler (so even a definition and declaration using different
names is OK).

This patch converts remaining files from the first half of the alphabet,
to keep the diff to a manageable size.

The conversion was done purely mechanically with:

  git ls-files '*.c' '*.h' |
  xargs perl -i -pe '
    s/ARGV_ARRAY/STRVEC/g;
    s/argv_array/strvec/g;
  '

and then selectively staging files with "git add '[abcdefghjkl]*'".
We'll deal with any indentation/style fallouts separately.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

strvec: convert builtin/ callers away from argv_array name

We eventually want to drop the argv_array name and just use strvec
consistently. There's no particular reason we have to do it all at once,
or care about interactions between converted and unconverted bits.
Because of our preprocessor compat layer, the names are interchangeable
to the compiler (so even a definition and declaration using different
names is OK).

This patch converts all of the files in builtin/ to keep the diff to a
manageable size.

The conversion was done purely mechanically with:

  git ls-files '*.c' '*.h' |
  xargs perl -i -pe '
    s/ARGV_ARRAY/STRVEC/g;
    s/argv_array/strvec/g;
  '

and then selectively staging files with "git add builtin/". We'll deal
with any indentation/style fallouts separately.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

quote: rename sq_dequote_to_argv_array to mention strvec

We want to eventually drop the use of the "argv_array" name in favor of
"strvec." Unlike most other uses of the name, this one is embedded in a
function name, so the definition and all of the callers need to be
updated at the same time.

We don't technically need to update the parameter types here (our
preprocessor compat macros make the two names interchangeable), but
let's do so to keep the site consistent for now.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

strvec: rename files from argv-array to strvec

This requires updating #include lines across the code-base, but that's
all fairly mechanical, and was done with:

  git ls-files '*.c' '*.h' |
  xargs perl -i -pe 's/argv-array.h/strvec.h/'

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

argv-array: rename to strvec

The name "argv-array" isn't very good, because it describes what the
data type can be used for (program argument arrays), not what it
actually is (a dynamically-growing string array that maintains a
NULL-terminator invariant). This leads to people being hesitant to use
it for other cases where it would actually be a good fit. The existing
name is also clunky to use. It's overly long, and the name often leads
to saying things like "argv.argv" (i.e., the field names overlap with
variable names, since they're describing the use, not the type). Let's
give it a more neutral name.

I settled on "strvec" because "vector" is the name for a dynamic array
type in many programming languages. "strarray" would work, too, but it's
longer and a bit more awkward to say (and don't we all say these things
in our mind as we type them?).

A more extreme direction would be a generic data structure which stores
a NULL-terminated of _any_ type. That would be easy to do with void
pointers, but we'd lose some type safety for the existing cases. Plus it
raises questions about memory allocation and ownership. So I limited
myself here to changing names only, and not semantics. If we do find a
use for that more generic data type, we could perhaps implement it at a
lower level and then provide type-safe wrappers around it for strings.
But that can come later.

This patch does the minimum to convert the struct and function names in
the header and implementation, leaving a few things for follow-on
patches:

  - files retain their original names for now

  - struct field names are retained for now

  - there's a preprocessor compat layer that lets most users remain the
    same for now. The exception is headers which made a manual forward
    declaration of the struct. I've converted them (and their dependent
    function declarations) here.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

argv-array: use size_t for count and alloc

On most 64-bit platforms, "int" is significantly smaller than a size_t,
which could lead to integer overflow and under-allocation of the array.
It's probably impossible to trigger in practice, as it would imply on
the order of 2^32 individual allocations. Even if was possible to grow
an array in that way (and we typically only use it for sets of strings,
like command line options), each allocation needs a pointer, malloc
overhead, etc. You'd quite likely run out of RAM before succeeding in
such an overflow.

But all that hand-waving aside, it's easy enough to use the correct
type, so let's do so.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

hashmap: fix typo in usage docs

Signed-off-by: Elijah Newren <redacted>
Signed-off-by: Junio C Hamano <redacted>

Remove doubled words in various comments

Signed-off-by: Elijah Newren <redacted>
Signed-off-by: Junio C Hamano <redacted>

Make HEAD a PSEUDOREF rather than PER_WORKTREE.

This is consistent with the definition of REF_TYPE_PSEUDOREF
(uppercase in the root ref namespace).

Signed-off-by: Han-Wen Nienhuys <redacted>
Signed-off-by: Junio C Hamano <redacted>

Modify pseudo refs through ref backend storage

The previous behavior was introduced in commit 74ec19d4be
("pseudorefs: create and use pseudoref update and delete functions",
Jul 31, 2015), with the justification "alternate ref backends still
need to store pseudorefs in GIT_DIR".

Refs such as REBASE_HEAD are read through the ref backend. This can
only work consistently if they are written through the ref backend as
well. Tooling that works directly on files under .git should be
updated to use git commands to read refs instead.

The following behaviors change:

* Updates to pseudorefs (eg. ORIG_HEAD) with
  core.logAllRefUpdates=always will create reflogs for the pseudoref.

* non-HEAD pseudoref symrefs are also dereferenced on deletion. Update
  t1405 accordingly.

Signed-off-by: Han-Wen Nienhuys <redacted>
Signed-off-by: Junio C Hamano <redacted>

Git 2.28

Signed-off-by: Junio C Hamano <redacted>

Merge tag 'l10n-2.28.0-rnd1' of https://github.com/git-l10n/git-po into master

l10n-2.28.0-rnd1

* tag 'l10n-2.28.0-rnd1' of https://www.github.com/git-l10n/git-po:
  l10n: es: 2.28.0 round 1
  l10n: de.po: Update German translation for Git v2.28.0
  l10n: de.po: fix grammar
  l10n: zh_CN: for git v2.28.0 l10n round 1
  l10n: zh_TW.po: v2.28.0 round 1 (0 untranslated)
  l10n: vi.po: correct "ident line" translation
  l10n: vi.po(4931t): Updated translation for v2.28.0
  l10n: fr v2.28.0 round 1
  l10n: sv.po: Update Swedish translation (4931t0f0u)
  l10n: it.po: update the Italian translation for Git 2.28.0 round 1
  l10n: tr: v2.28.0 round 1
  l10n: git.pot: v2.28.0 round 1 (70 new, 14 removed)
  l10n: Update Catalan translation

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

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

l10n: es: 2.28.0 round 1

Signed-off-by: Christopher Diaz Riveros <redacted>

Merge branch 'ps/ref-transaction-hook' into master

A new hook.

* ps/ref-transaction-hook:
  githooks.txt: use correct "reference-transaction" hook name

githooks.txt: use correct "reference-transaction" hook name

The "reference transaction" hook was introduced in commit 6754159767
(refs: implement reference transaction hook, 2020-06-19). The name of
the hook is declared as "reference-transaction" in "refs.c" and
testcases, but the name declared in "githooks.txt" is different.

Signed-off-by: Bojun Chen <redacted>
Reviewed-by: Patrick Steinhardt <redacted>
Signed-off-by: Junio C Hamano <redacted>

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

Reviewed-by: Ralf Thielow <redacted>
Signed-off-by: Matthias Rüster <redacted>

l10n: de.po: fix grammar

Signed-off-by: Ralf Thielow <redacted>
Signed-off-by: Matthias Rüster <redacted>

git-send-email: die if sendmail.* config is set

I've seen several people mis-configure git send-email on their first
attempt because they set the sendmail.* config options - not
sendemail.*. This patch detects this mistake and bails out with a
friendly warning.

Signed-off-by: Drew DeVault <redacted>
Signed-off-by: Junio C Hamano <redacted>

ci: use absolute PYTHON_PATH in the Linux jobs

In our test suite, when 'git p4' invokes a Git command as a
subprocesses, then it should run the 'git' binary we are testing.
Unfortunately, this is not the case in the 'linux-clang' and
'linux-gcc' jobs on Travis CI, where 'git p4' runs the system
'/usr/bin/git' instead.

Travis CI's default Linux image includes 'pyenv', and all Python
invocations that involve PATH lookup go through 'pyenv', e.g. our
'PYTHON_PATH=$(which python3)' sets '/opt/pyenv/shims/python3' as
PYTHON_PATH, which in turn will invoke '/usr/bin/python3'.  Alas, the
'pyenv' version included in this image is buggy, and prepends the
directory containing the Python binary to PATH even if that is a
system directory already in PATH near the end.  Consequently, 'git p4'
in those jobs ends up with its PATH starting with '/usr/bin', and then
runs '/usr/bin/git'.

So use the absolute paths '/usr/bin/python{2,3}' explicitly when
setting PYTHON_PATH in those Linux jobs to avoid the PATH lookup and
thus the bogus 'pyenv' from interfering with our 'git p4' tests.
Don't bother with special-casing Travis CI: while this issue doesn't
affect the corresponding Linux jobs on GitHub Actions, both CI systems
use Ubuntu LTS-based images, so we can safely rely on these Python
paths.

Signed-off-by: SZEDER Gábor <redacted>
Signed-off-by: Junio C Hamano <redacted>

pack-write/docs: update regarding pack naming

The index-pack documentation explicitly states that the pack
name is derived from the sorted list of object names, but
since commit 1190a1acf800 ("pack-objects: name pack files
after trailer hash") that isn't true anymore.

Be less explicit in the docs as to what the exact output is,
and just say that it's whatever goes into the pack name.

Also update a comment on write_idx_file() since it no longer
modifies the sha1 variable (it's const now anyway), as noted
by Junio.

Fixes: 1190a1acf800 ("pack-objects: name pack files after trailer hash")
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation/RelNotes: fix a typo in 2.28's relnotes

Signed-off-by: Taylor Blau <redacted>
Signed-off-by: Junio C Hamano <redacted>

Git 2.28-rc2

Signed-off-by: Junio C Hamano <redacted>

sha1-file: make pretend_object_file() not prefetch

When pretend_object_file() is invoked with an object that does not exist
(as is the typical case), there is no need to fetch anything from the
promisor remote, because the caller already knows what the object is
supposed to contain. Therefore, suppress the fetch. (The
OBJECT_INFO_QUICK flag is added for the same reason.)

This was noticed at $DAYJOB when "blame" was run on a file that had
uncommitted modifications.

Signed-off-by: Jonathan Tan <redacted>
Signed-off-by: Junio C Hamano <redacted>

pack-objects: prefetch objects to be packed

When an object to be packed is noticed to be missing, prefetch all
to-be-packed objects in one batch.

Signed-off-by: Jonathan Tan <redacted>
Signed-off-by: Junio C Hamano <redacted>

pack-objects: refactor to oid_object_info_extended

Use oid_object_info_extended() instead of oid_object_info() because a
subsequent commit needs to specify an additional flag here.

Signed-off-by: Jonathan Tan <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge branch 'en/sparse-status' into master

Fix to a "git prompt" regression during this development cycle.

* en/sparse-status:
  git-prompt: change == to = for zsh's sake

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

Translate 70 new messages (4931t0f0u) for git 2.28.0.

Reviewed-by: Fangyi Zhou <redacted>
Signed-off-by: Jiang Xin <redacted>

Merge branch 'l10n/zh_TW/200716' of github.com:l10n-tw/git-po

* 'l10n/zh_TW/200716' of github.com:l10n-tw/git-po:
  l10n: zh_TW.po: v2.28.0 round 1 (0 untranslated)

remote-curl: make --force-with-lease work with non-ASCII ref names

When we invoke a remote transport helper and pass an option with an
argument, we quote the argument as a C-style string if necessary.  This
is the case for the cas option, which implements the --force-with-lease
command-line flag, when we're passing a non-ASCII refname.

However, the remote curl helper isn't designed to parse such an
argument, meaning that if we try to use --force-with-lease with an HTTP
push and a non-ASCII refname, we get an error like this:

  error: cannot parse expected object name '0000000000000000000000000000000000000000"'

Note the double quote, which get_oid has reminded us is not valid in an
hex object ID.

Even if we had been able to parse it, we would send the wrong data to
the server: we'd send an escaped ref, which would not behave as the user
wanted and might accidentally result in updating or deleting a ref we
hadn't intended.

Since we need to expect a quoted C-style string here, just check if the
first argument is a double quote, and if so, unquote it.  Note that if
the refname contains a double quote, then we will have double-quoted it
already, so there is no ambiguity.

We test for this case only in the smart protocol, since the DAV-based
protocol is not capable of handling this capability.  We use UTF-8
because this is nicer in our tests and friendlier to Windows, but the
code should work for all non-ASCII refs.

While we're at it, since the name of the option is now well established
and isn't going to change, let's inline it instead of using the #define
constant.

Reported-by: Frej Bjon <redacted>
Signed-off-by: brian m. carlson <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-prompt: change == to = for zsh's sake

When using git-prompt.sh with zsh, __git_ps1 currently errs
when inside a repo with:

__git_ps1:96: = not found

Avoid using non-portable "==" that is only understood by bash
and not zsh. Change to "=" so that the prompt script becomes
usable with zsh again.

Signed-off-by: David J. Malan <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-mv: improve error message for conflicted file

'git mv' has always complained about renaming a conflicted
file, as it cannot handle multiple index entries for one file.
However, the error message it uses has been the same as the
one for an untracked file:

    fatal: not under version control, src=...

which is patently wrong.  Distinguish the two cases and
add a test to make sure we produce the correct message.

Signed-off-by: Chris Torek <redacted>
Signed-off-by: Junio C Hamano <redacted>

dir: check pathspecs before returning `path_excluded`

In 95c11ecc73 ("Fix error-prone fill_directory() API; make it only
return matches", 2020-04-01), we taught `fill_directory()`, or more
specifically `treat_path()`, to check against any pathspecs so that we
could simplify the callers.

But in doing so, we added a slightly-too-early return for the "excluded"
case. We end up not checking the pathspecs, meaning we return
`path_excluded` when maybe we should return `path_none`. As a result,
`git status --ignored -- pathspec` might show paths that don't actually
match "pathspec".

Move the "excluded" check down to after we've checked any pathspecs.

Reported-by: Andreas Schwab <redacted>
Reviewed-by: Elijah Newren <redacted>
Signed-off-by: Martin Ågren <redacted>
Signed-off-by: Junio C Hamano <redacted>

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

* https://github.com/prati0100/git-gui:
  git-gui: allow opening work trees from the startup dialog

l10n: zh_TW.po: v2.28.0 round 1 (0 untranslated)

Signed-off-by: Yi-Jyun Pan <redacted>

l10n: vi.po: correct "ident line" translation

While we're at it, fix some minor misspelling
and improve translation for 3-way-merging.

Signed-off-by: Đoàn Trần Công Danh <redacted>
Signed-off-by: Tran Ngoc Quan <redacted>

l10n: vi.po(4931t): Updated translation for v2.28.0

Signed-off-by: Tran Ngoc Quan <redacted>

Merge branch 'dl/branch-cleanup' into master

Last minute fix-up to tests for portability.

* dl/branch-cleanup:
  t3200: don't grep for `strerror()` string

Merge branch 'js/pu-to-seen' into master

Last minute fix-up to documentation.

* js/pu-to-seen:
  gitworkflows.txt: fix broken subsection underline

Merge branch 'jc/relnotes-v0-extension-update' into master

Last minute fix-up to the release notes.

* jc/relnotes-v0-extension-update:
  RelNotes: update the v0 with extension situation