index-pack: remove redundant child field

This is refactoring 1 of 2 to simplify struct base_data.

In index-pack, each thread maintains a doubly-linked list of the delta
chain that it is currently processing (the "base" and "child" pointers
in struct base_data). When a thread exceeds the delta base cache limit
and needs to reclaim memory, it uses the "child" pointers to traverse
the lineage, reclaiming the memory of the eldest delta bases first.

A subsequent patch will perform memory reclaiming in a different way and
will thus no longer need the "child" pointer. Because the "child"
pointer is redundant even now, remove it so that the aforementioned
subsequent patch will be clearer. In the meantime, reclaim memory in the
reverse order of the "base" pointers.

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

index-pack: unify threaded and unthreaded code

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

index-pack: remove redundant parameter

find_{ref,ofs}_delta_{,children} take an enum object_type parameter, but
the object type is already present in the name of the function. Remove
that parameter from these functions.

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

Documentation: deltaBaseCacheLimit is per-thread

Clarify that core.deltaBaseCacheLimit is per-thread, as can be seen from
the fact that cache usage (base_cache_used in struct thread_local in
builtin/index-pack.c) is tracked individually for each thread and
compared against delta_base_cache_limit.

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

Ninth batch

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

Merge branch 'jh/mingw-unlink'

"unlink" emulation on MinGW has been optimized.

* jh/mingw-unlink:
  mingw: improve performance of mingw_unlink()

Merge branch 'ds/sha256-leftover-bits'

midx and commit-graph files now use the byte defined in their file
format specification for identifying the hash function used for
object names.

* ds/sha256-leftover-bits:
  multi-pack-index: use hash version byte
  commit-graph: use the "hash version" byte
  t/README: document GIT_TEST_DEFAULT_HASH

Merge branch 'ma/sha-256-docs'

Further update of docs to adjust to the recent SHA-256 work.

* ma/sha-256-docs:
  shallow.txt: document SHA-256 shallow format
  protocol-capabilities.txt: clarify "allow-x-sha1-in-want" re SHA-256
  index-format.txt: document SHA-256 index format
  http-protocol.txt: document SHA-256 "want"/"have" format

Merge branch 'jc/object-names-are-not-sha-1'

A few end-user facing messages have been updated to be
hash-algorithm agnostic.

* jc/object-names-are-not-sha-1:
  messages: avoid SHA-1 in end-user facing messages

Merge branch 'bc/sha-256-doc-updates'

Further update of docs to adjust to the recent SHA-256 work.

* bc/sha-256-doc-updates:
  docs: fix step in transition plan
  docs: document SHA-256 pack and indices

Merge branch 'pb/set-url-docfix'

Doc fix.

* pb/set-url-docfix:
  fetch, pull doc: correct description of '--set-upstream'

Merge branch 'pb/userdiff-fortran-update'

The regexp to identify the function boundary for FORTRAN programs
has been updated.

* pb/userdiff-fortran-update:
  userdiff: improve Fortran xfuncname regex
  userdiff: add tests for Fortran xfuncname regex

Merge branch 'jb/commit-graph-doc-fix'

Docfix.

* jb/commit-graph-doc-fix:
  docs: commit-graph: fix some whitespace in the diagram

Merge branch 'jk/blame-coalesce-fix'

When given more than one target line ranges, "git blame -La,b
-Lc,d" was over-eager to coalesce groups of original lines and
showed incorrect results, which has been corrected.

* jk/blame-coalesce-fix:
  blame: only coalesce lines that are adjacent in result
  t8003: factor setup out of coalesce test
  t8003: check output of coalesced blame

Merge branch 'ak/sequencer-fix-find-uniq-abbrev'

Ring buffer with size 4 used for bin-hex translation resulted in a
wrong object name in the sequencer's todo output, which has been
corrected.

* ak/sequencer-fix-find-uniq-abbrev:
  rebase -i: fix possibly wrong onto hash in todo

Merge branch 'en/sequencer-merge-labels'

The commit labels used to explain each side of conflicted hunks
placed by the sequencer machinery have been made more readable by
humans.

* en/sequencer-merge-labels:
  sequencer: avoid garbled merge machinery messages due to commit labels

Merge branch 'rs/preserve-merges-unused-code-removal'

Code clean-up.

* rs/preserve-merges-unused-code-removal:
  rebase: remove unused function reschedule_last_action

Merge branch 'rs/upload-pack-sigchain-fix'

Code clean-up.

* rs/upload-pack-sigchain-fix:
  upload-pack: remove superfluous sigchain_pop() call

Merge branch 'rp/ita-diff-modefix'

"git diff [<tree-ish>] $path" for a $path that is marked with i-t-a
bit was not showing the mode bits from the working tree.

* rp/ita-diff-modefix:
  diff-lib: use worktree mode in diffs from i-t-a entries

Merge branch 'en/merge-tests'

Updates to "git merge" tests, in preparation for a new merge
strategy backend.

* en/merge-tests:
  t6425: be more flexible with rename/delete conflict messages
  t642[23]: be more flexible for add/add conflicts involving pair renames
  t6422, t6426: be more flexible for add/add conflicts involving renames
  t6423: add an explanation about why one of the tests does not pass
  t6416, t6423: clarify some comments and fix some typos
  t6422: fix multiple errors with the mod6 test expectations
  t6423: fix test setup for a couple tests
  t6416, t6422: fix incorrect untracked file count
  t6422: fix bad check against missing file
  t6418: tighten delete/normalize conflict testcase
  Collect merge-related tests to t64xx

Eighth batch

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

Merge branch 'so/log-diff-merges-opt'

Earlier, to countermand the implicit "-m" option when the
"--first-parent" option is used with "git log", we added the
"--[no-]diff-merges" option in the jk/log-fp-implies-m topic.  To
leave the door open to allow the "--diff-merges" option to take
values that instructs how patches for merge commits should be
computed (e.g. "cc"? "-p against first parent?"), redefine
"--diff-merges" to take non-optional value, and implement "off"
that means the same thing as "--no-diff-merges".

* so/log-diff-merges-opt:
  t/t4013: add test for --diff-merges=off
  doc/git-log: describe --diff-merges=off
  revision: change "--diff-merges" option to require parameter

Merge branch 'jk/log-fp-implies-m'

"git log --first-parent -p" showed patches only for single-parent
commits on the first-parent chain; the "--first-parent" option has
been made to imply "-m".  Use "--no-diff-merges" to restore the
previous behaviour to omit patches for merge commits.

* jk/log-fp-implies-m:
  doc/git-log: clarify handling of merge commit diffs
  doc/git-log: move "-t" into diff-options list
  doc/git-log: drop "-r" diff option
  doc/git-log: move "Diff Formatting" from rev-list-options
  log: enable "-m" automatically with "--first-parent"
  revision: add "--no-diff-merges" option to counteract "-m"
  log: drop "--cc implies -m" logic

Merge branch 'ma/stop-progress-null-fix'

NULL dereference fix.

* ma/stop-progress-null-fix:
  progress: don't dereference before checking for NULL

Merge branch 'es/test-cmp-typocatcher'

Test framework update.

* es/test-cmp-typocatcher:
  test_cmp: diagnose incorrect arguments

Merge branch 'rp/apply-cached-with-i-t-a'

Recent versions of "git diff-files" shows a diff between the index
and the working tree for "intent-to-add" paths as a "new file"
patch; "git apply --cached" should be able to take "git diff-files"
and should act as an equivalent to "git add" for the path, but the
command failed to do so for such a path.

* rp/apply-cached-with-i-t-a:
  t4140: test apply with i-t-a paths
  apply: make i-t-a entries never match worktree
  apply: allow "new file" patches on i-t-a entries

Merge branch 'al/bisect-first-parent'

"git bisect" learns the "--first-parent" option to find the first
breakage along the first-parent chain.

* al/bisect-first-parent:
  bisect: combine args passed to find_bisection()
  bisect: introduce first-parent flag
  cmd_bisect__helper: defer parsing no-checkout flag
  rev-list: allow bisect and first-parent flags
  t6030: modernize "git bisect run" tests

Merge branch 'jk/sideband-error-l10n'

Mark error message for i18n.

* jk/sideband-error-l10n:
  sideband: mark "remote error:" prefix for translation

Merge branch 'jc/noop-with-static-inline'

A no-op replacement function implemented as a C preprocessor macro
does not perform as good a job as one implemented as a "static
inline" function in catching errors in parameters; replace the
former with the latter in <git-compat-util.h> header.

* jc/noop-with-static-inline:
  compat-util: type-check parameters of no-op replacement functions

Merge branch 'pd/mergetool-nvimdiff'

The existing backends for "git mergetool" based on variants of vim
have been refactored and then support for "nvim" has been added.

* pd/mergetool-nvimdiff:
  mergetools: add support for nvimdiff (neovim) family
  mergetool--lib: improve support for vimdiff-style tool variants

Merge branch 'hn/reftable-prep-part-2'

Further preliminary change to refs API.

* hn/reftable-prep-part-2:
  Make HEAD a PSEUDOREF rather than PER_WORKTREE.
  Modify pseudo refs through ref backend storage
  t1400: use git rev-parse for testing PSEUDOREF existence

Merge branch 'dd/send-email-config'

Stop when "sendmail.*" configuration variables are defined, which
could be a mistaken attempt to define "sendemail.*" variables.

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

Merge branch 'ps/ref-transaction-hook'

The logic to find the ref transaction hook script attempted to
cache the path to the found hook without realizing that it needed
to keep a copied value, as the API it used returned a transitory
buffer space.  This has been corrected.

* ps/ref-transaction-hook:
  t1416: avoid hard-coded sha1 ids
  refs: fix interleaving hook calls with reference-transaction hook

multi-pack-index: use hash version byte

Similar to the commit-graph format, the multi-pack-index format has a
byte in the header intended to track the hash version used to write the
file. This allows one to interpret the hash length without having the
context of the repository config specifying the hash length. This was
not modified as part of the SHA-256 work because the hash length was
automatically up-shifted due to that config.

Since we have this byte available, we can make the file formats more
obviously incompatible instead of relying on other context from the
repository.

Add a new oid_version() method in midx.c similar to the one in
commit-graph.c. This is specifically made separate from that
implementation to avoid artificially linking the formats.

The test impact requires a few more things than the corresponding change
in the commit-graph format. Specifically, 'test-tool read-midx' was not
writing anything about this header value to output. Since the value
available in 'struct multi_pack_index' is hash_len instead of a version
value, we output "20" or "32" instead of "1" or "2".

Since we want a user to not have their Git commands fail if their
multi-pack-index has the incorrect hash version compared to the
repository's hash version, we relax the die() to an error() in
load_multi_pack_index(). This has some effect on 'git multi-pack-index
verify' as we need to check that a failed parse of a file that exists is
actually a verify error. For that test that checks the hash version
matches, we change the corrupted byte from "2" to "3" to ensure the test
fails for both hash algorithms.

Helped-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Reviewed-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit-graph: use the "hash version" byte

The commit-graph format reserved a byte among the header of the file to
store a "hash version". During the SHA-256 work, this was not modified
because file formats are not necessarily intended to work across hash
versions. If a repository has SHA-256 as its hash algorithm, it
automatically up-shifts the lengths of object names in all necessary
formats.

However, since we have this byte available for adjusting the version, we
can make the file formats more obviously incompatible instead of relying
on other context from the repository.

Update the oid_version() method in commit-graph.c to add a new value, 2,
for sha-256. This automatically writes the new value in a SHA-256
repository _and_ verifies the value is correct. This is a breaking
change relative to the current 'master' branch since 092b677 (Merge
branch 'bc/sha-256-cvs-svn-updates', 2020-08-13) but it is not breaking
relative to any released version of Git.

The test impact is relatively minor: the output of 'test-tool
read-graph' lists the header information, so those instances of '1' need
to be replaced with a variable determined by GIT_TEST_DEFAULT_HASH. A
more careful test is added that specifically creates a repository of
each type then swaps the commit-graph files. The important value here is
that the "git log" command succeeds while writing a message to stderr.

Helped-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Reviewed-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/README: document GIT_TEST_DEFAULT_HASH

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Reviewed-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: improve performance of mingw_unlink()

Update mingw_unlink() to first try to delete the file with existing
permissions before trying to force it.

Windows throws an error when trying to delete a read-only file.  The
mingw_unlink() compatibility wrapper always tries to _wchmod(666) the
file before calling _wunlink() to avoid that error.  However, since
most files in the worktree are already writable, this is usually
wasted effort.

Update mingw_unlink() to just call DeleteFileW() directly and if that
succeeds return.  If that fails, fall back into the existing code path
to update the permissions and use _wunlink() to get the existing
error code mapping.

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

shallow.txt: document SHA-256 shallow format

Similar to recent commits, document that we list object names rather
than SHA-1s.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

protocol-capabilities.txt: clarify "allow-x-sha1-in-want" re SHA-256

Two of our capabilities contain "sha1" in their names, but that's
historical. Clarify that object names are still to be given using
whatever object format has been negotiated using the "object-format"
capability.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

index-format.txt: document SHA-256 index format

Document that in SHA-1 repositories, we use SHA-1 and in SHA-256
repositories, we use SHA-256, then replace all other uses of "SHA-1"
with something more neutral. Avoid referring to "160-bit" hash values.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http-protocol.txt: document SHA-256 "want"/"have" format

Document that rather than always naming objects using SHA-1, we should
use whatever has been negotiated using the object-format capability.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sequencer: avoid garbled merge machinery messages due to commit labels

sequencer's get_message() exists to provide good labels on conflict
hunks; see commits
  d68565402a ("revert: clarify label on conflict hunks", 2010-03-20)
  bf975d379d ("cherry-pick, revert: add a label for ancestor", 2010-03-20)
  043a4492b3 ("sequencer: factor code out of revert builtin", 2012-01-11).
for background on this function.  These labels are of the form
  <commitID>... <commit summary>
or
  parent of <commitID>... <commit summary>
These labels are then passed as branch names to the merge machinery.
However, these labels, as formatted, often also serve to confuse.  For
example, if we have a rename involved in a content merge, then it
results in text such as the following:

    <<<<<<<< HEAD:foo.c
      int j;
    ========
      int counter;
    >>>>>>>> b01dface... Removed unnecessary stuff:bar.c

Or in various conflict messages, it can make it very difficult to read:

    CONFLICT (rename/delete): foo.c deleted in b01dface... Removed
    unnecessary stuff and renamed in HEAD.  Version HEAD of foo.c left
    in tree.

    CONFLICT (file location): dir1/foo.c added in b01dface... Removed
    unnecessary stuff inside a directory that was renamed in HEAD,
    suggesting it should perhaps be moved to dir2/foo.c.

Make a minor change to remove the ellipses and add parentheses around
the commit summary; this makes all three examples much easier to read:

    <<<<<<<< HEAD:foo.c
      int j;
    ========
      int counter;
    >>>>>>>> b01dface (Removed unnecessary stuff):bar.c

    CONFLICT (rename/delete): foo.c deleted in b01dface (Removed
    unnecessary stuff) and renamed in HEAD.  Version HEAD of foo.c left
    in tree.

    CONFLICT (file location): dir1/foo.c added in b01dface (Removed
    unnecessary stuff) inside a directory that was renamed in HEAD,
    suggesting it should perhaps be moved to dir2/foo.c.

Signed-off-by: Elijah Newren <newren@gmail.com>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

messages: avoid SHA-1 in end-user facing messages

There are still a handful mentions of SHA-1 when we meant the
(hexadecimal) object names in end-user facing messages.  Rewrite
them.

I was hoping that this can mostly be s/SHA-1/object name/, but
a few messages needed rephrasing to keep the result readable.

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

docs: fix step in transition plan

One of the required steps for the objectFormat extension is to implement
the loose object index.  However, without support for
compatObjectFormat, we don't even know if the loose object index is
needed, so it makes sense to move that step to the compatObjectFormat
section.  Do so.

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

docs: document SHA-256 pack and indices

Now that we have SHA-256 support for packs and indices, let's document
that in SHA-256 repositories, we use SHA-256 instead of SHA-1 for object
names and checksums.  Instead of duplicating this information throughout
the document, let's just document that in SHA-1 repositories, we use
SHA-1 for these purposes, and in SHA-256 repositories, we use SHA-256.

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

Seventh batch

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

Merge branch 'rp/blame-first-parent-doc'

The "git blame --first-parent" option was not documented, but now
it is.

* rp/blame-first-parent-doc:
  blame-options.txt: document --first-parent option

Merge branch 'ma/test-quote-cleanup'

Test cleanup.

* ma/test-quote-cleanup:
  t4104: modernize and simplify quoting
  t: don't spuriously close and reopen quotes

Merge branch 'jt/has_object'

A new helper function has_object() has been introduced to make it
easier to mark object existence checks that do and don't want to
trigger lazy fetches, and a few such checks are converted using it.

* jt/has_object:
  fsck: do not lazy fetch known non-promisor object
  pack-objects: no fetch when allow-{any,promisor}
  apply: do not lazy fetch when applying binary
  sha1-file: introduce no-lazy-fetch has_object()

Merge branch 'bc/sha-256-cvs-svn-updates'

Portability fix.

* bc/sha-256-cvs-svn-updates:
  git-cvsexportcommit: support Perl before 5.10.1

rebase -i: fix possibly wrong onto hash in todo

'todo_list_write_to_file' may overwrite the static buffer, originating
from 'find_unique_abbrev', that was used to store the short commit hash
'c' for "# Rebase a..b onto c" message in the todo editor. This is
because the buffer that is returned from 'find_unique_abbrev' is valid
until 4 more calls to `find_unique_abbrev` are made.

As 'todo_list_write_to_file' calls 'find_unique_abbrev' for each rebased
commit, the hash for 'c' is overwritten if there are 4 or more commits
in the rebase. This behavior has been broken since its introduction.

Fix by storing the short onto commit hash in a different buffer that
remains valid, before calling 'todo_list_write_to_file'.

Found-by: Jussi Keränen <jussike@gmail.com>
Signed-off-by: Antti Keränen <detegr@rbx.email>
Acked-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

userdiff: improve Fortran xfuncname regex

The third part of the Fortran xfuncname regex wants to match the
beginning of a subroutine or function, so it allows for all characters
except `'`, `"` or whitespace before the keyword 'function' or
'subroutine'. This is meant to match the 'recursive', 'elemental' or
'pure' keywords, as well as function return types, and to prevent
matches inside strings.

However, the negated set does not contain the `!` comment character,
so a line with an end-of-line comment containing the keyword 'function' or
'subroutine' followed by another word is mistakenly chosen as a hunk header.

Improve the regex by adding `!` to the negated set.

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

userdiff: add tests for Fortran xfuncname regex

The Fortran userdiff patterns, introduced in 909a5494f8 (userdiff.c: add
builtin fortran regex patterns, 2010-09-10), predate the test
infrastructure for xfuncname patterns, introduced in bfa7d01413 (t4018:
an infrastructure to test hunk headers, 2014-03-21).

Add tests for the Fortran xfuncname patterns. The test
't/t4018/fortran-comment-keyword' documents a shortcoming of the regex
that is fixed in a subsequent commit.

While at it, add descriptive comments for the different parts of the
regex.

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

fetch, pull doc: correct description of '--set-upstream'

The '--set-upstream' option to `git fetch` (which is also accepted by
`git pull` and passed through to the underlying `git fetch`) allows
setting the upstream configuration for the current branch. This was
added in 24bc1a1292 (pull, fetch: add --set-upstream option,
2019-08-19).

However, the documentation for that option describes its action as 'If
the remote is fetched successfully, pull and add upstream (tracking)
reference [...]', which is wrong because this option does not cause
neither `git fetch` nor `git pull` to pull: `git fetch` does not pull
and `git pull` always pulls.

Fix the description of that option.

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

docs: commit-graph: fix some whitespace in the diagram

In the merge diagram, some whitespace is missing which
makes it a bit confusing, fix that.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

blame: only coalesce lines that are adjacent in result

After blame has finished but before we produce any output, we coalesce
groups of lines that were adjacent in the original suspect (which may
have been split apart by lines in intermediate commits which went away).
However, this can cause incorrect output if the lines are not also
adjacent in the result. For instance, the case in t8003 has:

  ABC
  DEF

which becomes

  ABC
  SPLIT
  DEF

Blaming only lines 1 and 3 in the result yields two blame groups (one
for each line) that were adjacent in the original. That's enough for us
to coalesce them into a single group, but that loses information: our
output routines assume they're adjacent in the result as well, and we
output:

  <oid> 1) ABC
  <oid> 2) SPLIT

This is nonsense for two reasons:

  - we were asked about line 3, not line 2; we should not output the
    SPLIT line at all

  - commit <oid> did not touch the SPLIT line at all! We found the
    correct blame for line 3, but the bug is actually in the output
    stage, which is showing the wrong line number and content from the
    final file.

We can fix this by only coalescing when both the suspect and result
lines are adjacent. That fixes this bug, but keeps coalescing in cases
where want it (e.g., the existing test in t8003 where SPLIT goes away,
and the lines really are adjacent in the result).

Reported-by: Nuthan Munaiah <nm6061@rit.edu>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t8003: factor setup out of coalesce test

In preparation for adding more tests of blame's coalesce code, let's
split the setup out from the first test, and give each of the commits
a more meaningful name:

  - $orig for the original source that added the lines

  - $split for the version where they are split apart

  - $final for the final version that re-joins them

That's not strictly necessary, but makes the follow-on tests less
brittle than relying on HEAD^, etc, to name the commits.

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

t8003: check output of coalesced blame

Commit f0cbe742f4 (blame: add a test to cover blame_coalesce(),
2019-06-20) added a test case where blame can usefully coalesce two
groups of lines. But since it relies on the normal blame output, it only
exercises the code and can't tell whether the lines were actually
joined into a single group.

However, by using --porcelain output, we can see how git-blame considers
the groupings (and likewise how the coalescing might have a real
user-visible impact for a tool that uses the porcelain-output
groupings). This lets us confirm that we are indeed coalescing correctly
(and the fact that this test case requires coalescing can be verified by
dropping the call to blame_coalesce(), causing the test to fail).

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

rebase: remove unused function reschedule_last_action

The only caller of reschedule_last_action was removed by ef64bb328df
(rebase: strip unused code in git-rebase--preserve-merges.sh,
2018-05-28); remove this unused shell function as well.

Signed-off-by: René Scharfe <l.s.r@web.de>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Sixth batch

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

Merge branch 'ss/cmake-build'

CMake support to build with MSVC for Windows bypassing the Makefile.

* ss/cmake-build:
  ci: modification of main.yml to use cmake for vs-build job
  cmake: support for building git on windows with msvc and clang.
  cmake: support for building git on windows with mingw
  cmake: support for testing git when building out of the source tree
  cmake: support for testing git with ctest
  cmake: installation support for git
  cmake: generate the shell/perl/python scripts and templates, translations
  Introduce CMake support for configuring Git

Merge branch 'tb/upload-pack-filters'

The component to respond to "git fetch" request is made more
configurable to selectively allow or reject object filtering
specification used for partial cloning.

* tb/upload-pack-filters:
  t5616: use test_i18ngrep for upload-pack errors
  upload-pack.c: introduce 'uploadpackfilter.tree.maxDepth'
  upload-pack.c: allow banning certain object filter(s)
  list_objects_filter_options: introduce 'list_object_filter_config_name'

Merge branch 'es/worktree-doc-cleanups'

Doc cleanup around "worktree".

* es/worktree-doc-cleanups:
  git-worktree.txt: link to man pages when citing other Git commands
  git-worktree.txt: make start of new sentence more obvious
  git-worktree.txt: fix minor grammatical issues
  git-worktree.txt: consistently use term "working tree"
  git-worktree.txt: employ fixed-width typeface consistently

Merge branch 'bc/sha-256-part-3'

The final leg of SHA-256 transition.

* bc/sha-256-part-3: (39 commits)
  t: remove test_oid_init in tests
  docs: add documentation for extensions.objectFormat
  ci: run tests with SHA-256
  t: make SHA1 prerequisite depend on default hash
  t: allow testing different hash algorithms via environment
  t: add test_oid option to select hash algorithm
  repository: enable SHA-256 support by default
  setup: add support for reading extensions.objectformat
  bundle: add new version for use with SHA-256
  builtin/verify-pack: implement an --object-format option
  http-fetch: set up git directory before parsing pack hashes
  t0410: mark test with SHA1 prerequisite
  t5308: make test work with SHA-256
  t9700: make hash size independent
  t9500: ensure that algorithm info is preserved in config
  t9350: make hash size independent
  t9301: make hash size independent
  t9300: use $ZERO_OID instead of hard-coded object ID
  t9300: abstract away SHA-1-specific constants
  t8011: make hash size independent
  ...

t/t4013: add test for --diff-merges=off

Signed-off-by: Sergey Organov <sorganov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc/git-log: describe --diff-merges=off

Signed-off-by: Sergey Organov <sorganov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revision: change "--diff-merges" option to require parameter

--diff-merges=off is the only accepted form for now, a synonym for
--no-diff-merges.

This patch is a preparation for adding more values, as well as supporting
--diff-merges=<parent>, where <parent> is single parent number to output diff
against.

Signed-off-by: Sergey Organov <sorganov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1416: avoid hard-coded sha1 ids

The test added by e5256c82e5 (refs: fix interleaving hook calls with
reference-transaction hook, 2020-08-07) uses hard-coded sha1 object ids
in its expected output. This causes it to fail when run with
GIT_TEST_DEFAULT_HASH=sha256.

Let's make use of the oid variables we define earlier, as the rest of
the nearby tests do.

Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

upload-pack: remove superfluous sigchain_pop() call

2997178ee6 (upload-pack: split check_unreachable() in two, prep for
get_reachable_list(), 2016-06-12) moved most code of has_unreachable()
into the new function do_reachable_revlist().  The latter takes care to
ignore SIGPIPE during its operations, and restores the original signal
handler before returning.

However, a sigchain_pop(SIGPIPE) call remained in the error handling
code of has_unreachable(), which does nothing because the stack is
empty after do_reachable_revlist() cleaned up after itself.  Remove it.

Signed-off-by: René Scharfe <l.s.r@web.de>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t6425: be more flexible with rename/delete conflict messages

t6425 was very picky about the exact output message produced by a
rename/delete conflict, in a way that just scratches the surface of the
mess that was built into merge-recursive.  The idea was that it would
try to find the possible combinations of different conflict types, and
when more than one was present for one path, it would try to provide a
combined message that covered all the cases.

There's a lot to unravel here...

First, there's a basic conflict type known as modify/delete, which is a
content conflict.  It occurs when one side deletes a file, but the other
modifies it.

There is also a path conflict known as a rename/delete.  This occurs
when one side deletes a path, and the other renames it.  This is not a
content conflict, it is a path conflict.  It will often occur in
combination with a content conflict, though, namely a modify/delete.  As
such, these two were often combined.

Another type of conflict that can exist is a directory/file conflict.
For example, one side adds a new file at some path, and the other side
of history adds a directory at the same path.  The path that was "added"
could have been put there by a rename, though.  Thus, we have the
possibility of a single path being affected by a modify/delete, a
rename/delete, and a directory/file conflict.

In part, this was a natural by-product of merge-recursive's design.
Since it was doing a four way merge with the contents of the working
tree being the fourth factor it had to consider, it had working tree
handling spread all over the code.  It also had directory/file conflict
handling spread everywhere through all the other types of conflicts.
And our testsuite has a huge number of directory/file conflict tests
because trying to get them right required modifying so many different
codepaths.  A natural outgrowth of this kind of structure is conflict
messages that combine all the different types that the current codepath
is considering.

However, if we want to make the different conflict types orthogonal and
avoid repeating ourselves and getting very brittle code, then we need to
split the messages from these different conflict types apart.  Besides,
trying to determine all possible permutations is a _royal_ mess.  The
code to handle the rename/delete/directory/file conflict output is
already somewhat hard to parse, and is somewhat brittle.  But if we
really wanted to go that route, then we'd have to have special handling
for the following types of combinations:
  * rename/add/delete:
      on side of history that didn't rename the given file, remove the file
      instead and place an unrelated file in the way of the rename
  * rename/rename(2to1)/mode conflict/delete/delete:
      two different files, one executable and the other not, are renamed
      to the same location, each side deletes the source file that the
      other side renames
  * rename/rename(1to2)/add/add:
      file renamed differently on each side of history, with each side
      placing an unrelated file in the way of the other
  * rename/rename(1to2)/content conflict/file location/(D/F)/(D/F)/:
      both sides modify a file in conflicting way, both rename that file
      but to different paths, one side renames the directory which the
      other side had renamed that file into causing it to possibly need a
      transitive rename, and each side puts a directory in the way of the
      other's path.

Let's back away from this path of insanity, and allow the different
types of conflicts to be handled by separate pieces of non-repeated code
by allowing the conflict messages to be split into their separate types.
(If multiple conflict types affect a single path, the conflict messages
can be printed sequentially.)  Start this path with a simple change:
modify this test to be more flexible and accept the output either merge
backend (recursive or the new ort) will produce.

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

t642[23]: be more flexible for add/add conflicts involving pair renames

Much like the last commit accepted 'add/add' and 'rename/add'
interchangably, we also want to do the same for 'add/add' and
'rename/rename'.  This also allows us to avoid the ambiguity in meaning
with 'rename/rename' (is it two separate files renamed to the same
location, or one file renamed on both sides but differently)?

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

t6422, t6426: be more flexible for add/add conflicts involving renames

merge-recursive treats an add/add conflict where one of the adds came
from a rename as a separate 'rename/add' type of conflict.  However, if
there is not content conflict after the content merge(s), then the file
is not considered to be conflicted.  That suggests the conflict type is
really just add/add.  Other merge engines might choose to print messages
to the console that just refer to these as add/add conflicts; accept
both types of output.

Note: it could help to notify users if the three-way content merge of
the rename had content conflicts, because when we then go to two-way
merge THAT with the conflicting add we can get nested conflict markers.
merge-recursive, unfortunately, doesn't do that, but other merge engines
could.

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

t6423: add an explanation about why one of the tests does not pass

I had long since forgotten the idea behind this test and why it failed,
and took a little while to figure it out.  To prevent others from having
to spend a similar time on it, add an explanation in the comments.
However, the reasoning in the explanation makes me question why I
considered it a failure at all.  I'm not sure if I had a better reason
when I originally wrote it, but for now just add commentary about the
possible expectations and why it behaves the way it does right now.

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

t6416, t6423: clarify some comments and fix some typos

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

t6422: fix multiple errors with the mod6 test expectations

This test had multiple issues causing it to fail for the wrong
reason(s):

  * rename/rename(1to2) conflicts have always left the original source
    path present in the working directory and index (at stage 1).  Thus,
    the triple rename/rename(1to2) should result in 9 unstaged files,
    not 6.
  * It messed up the three-way content merge for checking the results of
    merging for one of the renames, accidentally turning it into a
    two-way merge.
  * It got the contents of the base files it was using to compare
    against wrong, due to an off-by-one error, and overwrite-redirection
    ('>') instead of append-redirection ('>>').
  * It used slightly too-long conflict markers
  * It didn't include filenames in the conflict marker hunks (granted,
    that was a shortcoming of the merge-recursive backend for rename/add
    and rename/rename(2to1) conflicts, but since it's
    test_expect_failure anyway we might as well make it expect our
    preferred behavior rather than some compromise that we can't yet
    reach anyway).

Fix these issues so that a merge backend which correctly handles these
kinds of nested conflicts will pass the test.

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

t6423: fix test setup for a couple tests

Commit da1e295e00 ("t604[236]: do not run setup in separate tests",
2019-10-22) removed approximately half the tests (which were setup-only
tests) in t6043 by turning them into functions that the subsequent test
would call as their first step.  This ensured that any test from this
file could be run entirely independently of all the other tests in the
file.  Unfortunately, the call to the new setup function was missed in
two of the test_expect_failure cases.  Add them in.

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

t6416, t6422: fix incorrect untracked file count

Apparently I don't know how to count untracked files, and since the
tests in question were marked as test_expect_failure, no one ever
noticed it until now.  Correct the count, as these tests clearly create
three untracked files ('out', 'err', and 'file_count').

(I believe this problem arose because earlier incarnations counted lines
via a pipe to 'wc -l'.  Reviewers asked that it be replaced by writing
the output to a file and using test_line_count, but when the temporary
output was added to a separate file, the count of untracked files should
have increased.)

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

t6422: fix bad check against missing file

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

t6418: tighten delete/normalize conflict testcase

The testcase only required that the merge complete without conflict,
without specifying what the correct resolution was.  Since normalization
changed this from a modify/delete to a not-modified/delete, the correct
resolution is to have the file be removed at the end.  Add a check for
this resolution.

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

Collect merge-related tests to t64xx

The tests for the merge machinery are spread over several places.
Collect them into t64xx for simplicity.  Some notes:

t60[234]*.sh:
  Merge tests started in t602*, overgrew bisect and remote tracking
  tests in t6030, t6040, and t6041, and nearly overtook replace tests
  in t6050.  This made picking out relevant tests that I wanted to run
  in a tighter loop slightly more annoying for years.

t303*.sh:
  These started out as tests for the 'merge-recursive' toplevel command,
  but did not restrict to that and had lots of overlap with the
  underlying merge machinery.
t7405, t7613:
  submodule-specific merge logic started out in submodule.c but was
  moved to merge-recursive.c in commit 18cfc08866 ("submodule.c: move
  submodule merging to merge-recursive.c", 2018-05-15).  Since these
  tests are about the logic found in the merge machinery, moving these
  tests to be with the merge tests makes sense.

t7607, t7609:
  Having tests spread all over the place makes it more likely that
  additional tests related to a certain piece of logic grow in all those
  other places.  Much like t303*.sh, these two tests were about the
  underlying merge machinery rather than outer levels.

Tests that were NOT moved:

t76[01]*.sh:
  Other than the four tests mentioned above, the remaining tests in
  t76[01]*.sh are related to non-recursive merge strategies, parameter
  parsing, and other stuff associated with the highlevel builtin/merge.c
  rather than the recursive merge machinery.

t3[45]*.sh:
  The rebase testcases in t34*.sh also test the merge logic pretty
  heavily; sometimes changes I make only trigger failures in the rebase
  tests.  The rebase tests are already nicely coupled together, though,
  and I didn't want to mess that up.  Similar comments apply for the
  cherry-pick tests in t35*.sh.

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

progress: don't dereference before checking for NULL

In `stop_progress()`, we're careful to check that `p_progress` is
non-NULL before we dereference it, but by then we have already
dereferenced it when calling `finish_if_sparse(*p_progress)`. And, for
what it's worth, we'll go on to blindly dereference it again inside
`stop_progress_msg()`.

We could return early if we get a NULL-pointer, but let's go one step
further and BUG instead. The progress API handles NULL just fine, but
that's the NULL-ness of `*p_progress`, e.g., when running with
`--no-progress`. If `p_progress` is NULL, chances are that's a mistake.
For symmetry, let's do the same check in `stop_progress_msg()`, too.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fifth batch

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

Merge branch 'pb/guide-docs'

Update "git help guides" documentation organization.

* pb/guide-docs:
  git.txt: add list of guides
  Documentation: don't hardcode command categories twice
  help: drop usage of 'common' and 'useful' for guides
  command-list.txt: add missing 'gitcredentials' and 'gitremote-helpers'

Merge branch 'so/rev-parser-errormessage-fix'

Error message fix.

* so/rev-parser-errormessage-fix:
  revision: fix die() message for "--unpacked="

Merge branch 'en/eol-attrs-gotchas'

All "mergy" operations that internally use the merge-recursive
machinery should honor the merge.renormalize configuration, but
many of them didn't.

* en/eol-attrs-gotchas:
  checkout: support renormalization with checkout -m <paths>
  merge: make merge.renormalize work for all uses of merge machinery
  t6038: remove problematic test
  t6038: make tests fail for the right reason

Merge branch 'jk/compiler-fixes-and-workarounds'

Small fixes and workarounds.

* jk/compiler-fixes-and-workarounds:
  revision: avoid leak when preparing bloom filter for "/"
  revision: avoid out-of-bounds read/write on empty pathspec
  config: work around gcc-10 -Wstringop-overflow warning

Merge branch 'ny/notes-doc-sample-update'

Doc updates.

* ny/notes-doc-sample-update:
  docs: improve the example that illustrates git-notes path names

Merge branch 'es/adjust-subtree-test-for-merge-msg-update'

Adjust tests in contrib/ to the recent change to fmt-merge-msg.

* es/adjust-subtree-test-for-merge-msg-update:
  Revert "contrib: subtree: adjust test to change in fmt-merge-msg"

Merge branch 'rs/bisect-oid-to-hex-fix'

Code cleanup.

* rs/bisect-oid-to-hex-fix:
  bisect: use oid_to_hex_r() instead of memcpy()+oid_to_hex()

Merge branch 'en/merge-recursive-comment-fixes'

Comment fix.

* en/merge-recursive-comment-fixes:
  merge-recursive: fix unclear and outright wrong comments

Merge branch 'ma/t1450-quotefix'

Test fix.

* ma/t1450-quotefix:
  t1450: fix quoting of NUL byte when corrupting pack

Merge branch 'es/worktree-cleanup'

Code cleanup around "worktree" API implementation.

* es/worktree-cleanup:
  worktree: retire special-case normalization of main worktree path
  worktree: drop bogus and unnecessary path munging
  worktree: drop unused code from get_linked_worktree()
  worktree: drop pointless strbuf_release()

Merge branch 'jk/strvec'

The argv_array API is useful for not just managing argv but any
"vector" (NULL-terminated array) of strings, and has seen adoption
to a certain degree.  It has been renamed to "strvec" to reduce the
barrier to adoption.

* jk/strvec:
  strvec: rename struct fields
  strvec: drop argv_array compatibility layer
  strvec: update documention to avoid argv_array
  strvec: fix indentation in renamed calls
  strvec: convert remaining callers away from argv_array name
  strvec: convert more callers away from argv_array name
  strvec: convert builtin/ callers away from argv_array name
  quote: rename sq_dequote_to_argv_array to mention strvec
  strvec: rename files from argv-array to strvec
  argv-array: rename to strvec
  argv-array: use size_t for count and alloc

test_cmp: diagnose incorrect arguments

Under normal circumstances, if a test author misspells a filename passed
to test_cmp(), the error is quickly discovered when the test fails
unexpectedly due to test_cmp() being unable to find the file. However,
if the test is expected to fail, as with test_expect_failure(), a
misspelled filename as argument to test_cmp() will go unnoticed since
the test will indeed fail, but for the wrong reason. Make it easier for
test authors to discover such problems early by sanity-checking the
arguments to test_cmp(). To avoid penalizing all clients of test_cmp()
in the general case, only check for missing files if the comparison
fails.

While at it, make test_cmp_bin() sanity-check its arguments, as well.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff-lib: use worktree mode in diffs from i-t-a entries

When creating "new file" diffs against i-t-a index entries, diff-lib
erroneously used the mode of the cache entry rather than the mode of the
file in the worktree. This changes run_diff_files() to correctly use the
mode of the worktree file in this case.

Signed-off-by: Raymond E. Pasco <ray@ameretat.dev>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t4140: test apply with i-t-a paths

apply --cached (as used by add -p) should accept creation and deletion
patches to intent-to-add paths in the index. apply --index, however,
should always fail because an intent-to-add path never matches the
worktree (by definition).

Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Raymond E. Pasco <ray@ameretat.dev>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

apply: make i-t-a entries never match worktree

By definition, an intent-to-add index entry can never match the
worktree, because worktrees have no concept of intent-to-add entries.
Therefore, "apply --index" should always fail on intent-to-add paths.

Because check_preimage() calls verify_index_match(), it already fails
for patches other than creation patches, which check_preimage() ignores.
This patch adds a check to check_preimage()'s rough equivalent for
creation patches, check_to_create().

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Raymond E. Pasco <ray@ameretat.dev>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: combine args passed to find_bisection()

Now that find_bisection() accepts multiple boolean arguments, these may
be combined into a single unsigned integer in order to declutter some of
the code in bisect.c

Also, rename the existing "flags" bitfield to "commit_flags", to
explicitly differentiate it from the new "bisect_flags" bitfield.

Based-on-patch-by: Harald Nordgren <haraldnordgren@gmail.com>
Signed-off-by: Aaron Lipman <alipman88@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: introduce first-parent flag

Upon seeing a merge commit when bisecting, this option may be used to
follow only the first parent.

In detecting regressions introduced through the merging of a branch, the
merge commit will be identified as introduction of the bug and its
ancestors will be ignored.

This option is particularly useful in avoiding false positives when a
merged branch contained broken or non-buildable commits, but the merge
itself was OK.

Signed-off-by: Aaron Lipman <alipman88@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

cmd_bisect__helper: defer parsing no-checkout flag

cmd_bisect__helper() is intended as a temporary shim layer serving as an
interface for git-bisect.sh. This function and git-bisect.sh should
eventually be replaced by a C implementation, cmd_bisect(), serving as
an entrypoint for all "git bisect ..." shell commands: cmd_bisect() will
only parse the first token following "git bisect", and dispatch the
remaining args to the appropriate function ["bisect_start()",
"bisect_next()", etc.].

Thus, cmd_bisect__helper() should not be responsible for parsing flags
like --no-checkout. Instead, let the --no-checkout flag remain in the
argv array, so it may be evaluated alongside the other options already
parsed by bisect_start().

Signed-off-by: Aaron Lipman <alipman88@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>