fsck: use oids rather than objects for object_name API

We don't actually care about having object structs; we only need to look
up decorations by oid. Let's accept this more limited form, which will
give our callers more flexibility.

Note that the decoration API we rely on uses object structs itself (even
though it only looks at their oids). We can solve this by switching to
a kh_oid_map (we could also use the hashmap oidmap, but it's more
awkward for the simple case of just storing a void pointer).

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

fsck_describe_object(): build on our get_object_name() primitive

This isolates the implementation detail of using the decoration code to
our put/get functions.

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

fsck: unify object-name code

Commit 90cf590f53 (fsck: optionally show more helpful info for broken
links, 2016-07-17) added a system for decorating objects with names. The
code is split across builtin/fsck.c (which gives the initial names) and
fsck.c (which adds to the names as it traverses the object graph). This
leads to some duplication, where both sites have near-identical
describe_object() functions (the difference being that the one in
builtin/fsck.c uses a circular array of buffers to allow multiple calls
in a single printf).

Let's provide a unified object_name API for fsck. That lets us drop the
duplication, as well as making the interface boundaries more clear
(which will let us refactor the implementation more in a future patch).

We'll leave describe_object() in builtin/fsck.c as a thin wrapper around
the new API, as it relies on a static global to make its many callers a
bit shorter.

We'll also convert the bare add_decoration() calls in builtin/fsck.c to
put_object_name(). This fixes two minor bugs:

  1. We leak many small strings. add_decoration() has a last-one-wins
     approach: it updates the decoration to the new string and returns
     the old one. But we ignore the return value, leaking the old
     string. This is quite common to trigger, since we look at reflogs:
     the tip of any ref will be described both by looking at the actual
     ref, as well as the latest reflog entry. So we'd always end up
     leaking one of those strings.

  2. The last-one-wins approach gives us lousy names. For instance, we
     first look at all of the refs, and then all of the reflogs. So
     rather than seeing "refs/heads/master", we're likely to overwrite
     it with "HEAD@{12345678}". We're generally better off using the
     first name we find.

     And indeed, the test in t1450 expects this ugly HEAD@{} name. After
     this patch, we've switched to using fsck_put_object_name()'s
     first-one-wins semantics, and we output the more human-friendly
     "refs/tags/julius" (and the test is updated accordingly).

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

fsck: require an actual buffer for non-blobs

The fsck_object() function takes in a buffer, but also a "struct
object". The rules for using these vary between types:

  - for a commit, we'll use the provided buffer; if it's NULL, we'll
    fall back to get_commit_buffer(), which loads from either an
    in-memory cache or from disk. If the latter fails, we'd die(), which
    is non-ideal for fsck.

  - for a tag, a NULL buffer will fall back to loading the object from
    disk (and failure would lead to an fsck error)

  - for a tree, we _never_ look at the provided buffer, and always use
    tree->buffer

  - for a blob, we usually don't look at the buffer at all, unless it
    has been marked as a .gitmodule file. In that case we check the
    buffer given to us, or assume a NULL buffer is a very large blob
    (and complain about it)

This is much more complex than it needs to be. It turns out that nobody
ever feeds a NULL buffer that isn't a blob:

  - git-fsck calls fsck_object() only from fsck_obj(). That in turn is
    called by one of:

      - fsck_obj_buffer(), which is a callback to verify_pack(), which
unpacks everything except large blobs into a buffer (see
pack-check.c, lines 131-141).

      - fsck_loose(), which hits a BUG() on non-blobs with a NULL buffer
(builtin/fsck.c, lines 639-640)

    And in either case, we'll have just called parse_object_buffer()
    anyway, which would segfault on a NULL buffer for commits or tags
    (not for trees, but it would install a NULL tree->buffer which would
    later cause a segfault)

  - git-index-pack asserts that the buffer is non-NULL unless the object
    is a blob (see builtin/index-pack.c, line 832)

  - git-unpack-objects always writes a non-NULL buffer into its
    obj_buffer hash, which is then fed to fsck_object(). (There is
    actually a funny thing here where it does not store blob buffers at
    all, nor does it call fsck on them; it does check any needed blobs
    via fsck_finish() though).

Let's make the rules simpler, which reduces the amount of code and gives
us more flexibility in refactoring the fsck code. The new rules are:

  - only blobs are allowed to pass a NULL buffer

  - we always use the provided buffer, never pulling information from
    the object struct

We don't have to adjust any callers, because they were already adhering
to these. Note that we do drop a few fsck identifiers for missing tags,
but that was all dead code (because nobody passed a NULL tag buffer).

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

fsck: stop checking tag->tagged

Way back in 92d4c85d24 (fsck-cache: fix SIGSEGV on bad tag object,
2005-05-03), we added an fsck check that the "tagged" field of a tag
struct isn't NULL. But that was mainly protecting the printing code for
"--tags", and that code wasn't moved along with the check as part of
ba002f3b28 (builtin-fsck: move common object checking code to fsck.c,
2008-02-25).

It could also serve to detect type mismatch problems (where a tag points
to object X as a commit, but really X is a blob), but it couldn't do so
reliably (we'd call lookup_commit(X), but it will only notice the
problem if we happen to have previously called lookup_blob(X) in the
same process). And as of a commit earlier in this series, we'd consider
that a parse error and complain about the object even before getting to
this point anyway.

So let's drop this "tag->tagged" check. It's not helping anything, and
getting rid of it makes the function conceptually cleaner, as it really
is just checking the buffer we feed it. In fact, we can get rid of our
one-line wrapper and just unify fsck_tag() and fsck_tag_buffer().

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

fsck: stop checking commit->parent counts

In 4516338243 (builtin-fsck: reports missing parent commits,
2008-02-25), we added code to check that fsck found the same number of
parents from parsing the commit itself as we see in the commit struct we
got from parse_commit_buffer(). Back then the rationale was that the
normal commit parser might skip some bad parents.

But earlier in this series, we started treating that reliably as a
parsing error, meaning that we'd complain about it before we even hit
the code in fsck.c.

Let's drop this code, which now makes fsck_commit_buffer() completely
independent of any parsed values in the commit struct (that's
conceptually cleaner, and also opens up more refactoring options).

Note that we can also drop the MISSING_PARENT and MISSING_GRAFT fsck
identifiers. This is no loss, as these would not trigger reliably
anyway.  We'd hit them only when lookup_commit() failed, which occurs
only if we happen to have seen the object with another type already in
the same process. In most cases, we'd actually run into the problem
during the connectivity walk, not here.

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

fsck: stop checking commit->tree value

We check in fsck_commit_buffer() that commit->tree isn't NULL, which in
turn generally comes from a previous parse by parse_commit(). But this
isn't really accomplishing anything. The two things we might care about
are:

  - was there a syntactically valid "tree <oid>" line in the object? But
    we've just done our own parse in fsck_commit_buffer() to check this.

  - does it point to a valid tree object? But checking the "tree"
    pointer here doesn't actually accomplish that; it just shows that
    lookup_tree() didn't return NULL, which only means that we haven't
    yet seen that oid as a non-tree in this process.

    A real connectivity check would exhaustively walk all graph links,
    and we do that already in a separate function.

So this code isn't helping anything. And it makes the fsck code slightly
more confusing and rigid (e.g., it requires that any commit structs have
already been parsed). Let's drop it.

As a bit of history, the presence of this code looks like a leftover
from early fsck code (which did rely on parse_commit() to do most of the
parsing). The check comes from ff5ebe39b0 (Port fsck-cache to use
parsing functions, 2005-04-18), but we later added an explicit walk in
355885d531 (add generic, type aware object chain walker, 2008-02-25).

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

commit, tag: don't set parsed bit for parse failures

If we can't parse a commit, then parse_commit() will return an error
code. But it _also_ sets the "parsed" flag, which tells us not to bother
trying to re-parse the object. That means that subsequent parses have no
idea that the information in the struct may be bogus.  I.e., doing this:

  parse_commit(commit);
  ...
  if (parse_commit(commit) < 0)
          die("commit is broken");

will never trigger the die(). The second parse_commit() will see the
"parsed" flag and quietly return success.

There are two obvious ways to fix this:

  1. Stop setting "parsed" until we've successfully parsed.

  2. Keep a second "corrupt" flag to indicate that we saw an error (and
     when the parsed flag is set, return 0/-1 depending on the corrupt
     flag).

This patch does option 1. The obvious downside versus option 2 is that
we might continually re-parse a broken object. But in practice,
corruption like this is rare, and we typically die() or return an error
in the caller. So it's OK not to worry about optimizing for corruption.
And it's much simpler: we don't need to use an extra bit in the object
struct, and callers which check the "parsed" flag don't need to learn
about the corrupt bit, too.

There's no new test here, because this case is already covered in t5318.
Note that we do need to update the expected message there, because we
now detect the problem in the return from "parse_commit()", and not with
a separate check for a NULL tree. In fact, we can now ditch that
explicit tree check entirely, as we're covered robustly by this change
(and the previous recent change to treat a NULL tree as a parse error).

We'll also give tags the same treatment. I don't know offhand of any
cases where the problem can be triggered (it implies somebody ignoring a
parse error earlier in the process), but consistently returning an error
should cause the least surprise.

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

parse_tag_buffer(): treat NULL tag pointer as parse error

When parsing a tag, we may end up with a NULL "tagged" field when
there's a type mismatch (e.g., the tag claims to point to object X as a
commit, but we previously saw X as a blob in the same process), but we
do not otherwise indicate a parse failure to the caller.

This is similar to the case discussed in the previous commit, where a
commit could end up with a NULL tree field: while slightly convenient
for callers who want to overlook a corrupt object, it means that normal
callers have to explicitly deal with this case (rather than just relying
on the return code from parsing). And most don't, leading to segfault
fixes like the one in c77722b3ea (use get_tagged_oid(), 2019-09-05).

Let's address this more centrally, by returning an error code from the
parse itself, which most callers would already notice (adventurous
callers are free to ignore the error and continue looking at the
struct).

This also covers the case where the tag contains a nonsensical "type"
field (there we produced a user-visible error but still returned success
to the caller; now we'll produce a slightly better message and return an
error).

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

parse_commit_buffer(): treat lookup_tree() failure as parse error

If parsing a commit yields a valid tree oid, but we've seen that same
oid as a non-tree in the same process, the resulting commit struct will
end up with a NULL tree pointer, but not otherwise report a parsing
failure.

That's perhaps convenient for callers which want to operate on even
partially corrupt commits (e.g., by still looking at the parents). But
it leaves a potential trap for most callers, who now have to manually
check for a NULL tree. Most do not, and it's likely that there are
possible segfaults lurking. I say "possible" because there are many
candidates, and I don't think it's worth following through on
reproducing them when we can just fix them all in one spot. And
certainly we _have_ seen real-world cases, such as the one fixed by
806278dead (commit-graph.c: handle corrupt/missing trees, 2019-09-05).

Note that we can't quite drop the check in the caller added by that
commit yet, as there's some subtlety with repeated parsings (which will
be addressed in a future commit).

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

parse_commit_buffer(): treat lookup_commit() failure as parse error

While parsing the parents of a commit, if we are able to parse an actual
oid but lookup_commit() fails on it (because we previously saw it in
this process as a different object type), we silently omit the parent
and do not report any error to the caller.

The caller has no way of knowing this happened, because even an empty
parent list is a valid parse result. As a result, it's possible to fool
our "rev-list" connectivity check into accepting a corrupted set of
objects.

There's a test for this case already in t6102, but unfortunately it has
a slight error. It creates a broken commit with a parent line pointing
to a blob, and then checks that rev-list notices the problem in two
cases:

  1. the "lone" case: we traverse the broken commit by itself (here we
     try to actually load the blob from disk and find out that it's not
     a commit)

  2. the "seen" case: we parse the blob earlier in the process, and then
     when calling lookup_commit() we realize immediately that it's not a
     commit

The "seen" variant for this test mistakenly parsed another commit
instead of the blob, meaning that we were actually just testing the
"lone" case again. Changing that reveals the breakage (and shows that
this fixes it).

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

Git 2.24-rc0

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

Merge branch 'rs/remote-curl-use-argv-array'

Code cleanup.

* rs/remote-curl-use-argv-array:
  remote-curl: use argv_array in parse_push()

Merge branch 'rs/column-use-utf8-strnwidth'

Code cleanup.

* rs/column-use-utf8-strnwidth:
  column: use utf8_strnwidth() to strip out ANSI color escapes

Merge branch 'rs/http-push-simplify'

Code cleanup.

* rs/http-push-simplify:
  http-push: simplify deleting a list item

Merge branch 'jj/stash-reset-only-toplevel'

"git stash save" lost local changes to submodules, which has been
corrected.

* jj/stash-reset-only-toplevel:
  stash: avoid recursive hard reset on submodules

Merge branch 'bw/format-patch-o-create-leading-dirs'

"git format-patch -o <outdir>" did an equivalent of "mkdir <outdir>"
not "mkdir -p <outdir>", which is being corrected.

* bw/format-patch-o-create-leading-dirs:
  format-patch: create leading components of output directory

Merge branch 'bb/compat-util-comment-fix'

Code cleanup.

* bb/compat-util-comment-fix:
  git-compat-util: fix documentation syntax

Merge branch 'bb/utf8-wcwidth-cleanup'

Code cleanup.

* bb/utf8-wcwidth-cleanup:
  utf8: use ARRAY_SIZE() in git_wcwidth()

Merge branch 'dl/allow-running-cocci-verbosely'

Dev support update.

* dl/allow-running-cocci-verbosely:
  Makefile: respect $(V) in %.cocci.patch target

Merge branch 'dl/compat-cleanup'

Code formatting micronit fix.

* dl/compat-cleanup:
  pthread.h: manually align parameter lists

Merge branch 'ta/t1308-typofix'

Test fix.

* ta/t1308-typofix:
  t1308-config-set: fix a test that has a typo

Merge branch 'js/doc-stash-save'

Doc clarification.

* js/doc-stash-save:
  doc(stash): clarify the description of `save`

Ninth batch

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

Merge branch 'jk/coc'

Code-of-conduct document.

* jk/coc:
  CODE_OF_CONDUCT: mention individual project-leader emails
  add a Code of Conduct document

Merge branch 'js/trace2-fetch-push'

Dev support.

* js/trace2-fetch-push:
  transport: push codepath can take arbitrary repository
  push: add trace2 instrumentation
  fetch: add trace2 instrumentation

Merge branch 'jt/push-avoid-lazy-fetch'

Performance hack.

* jt/push-avoid-lazy-fetch:
  send-pack: never fetch when checking exclusions

Merge branch 'dl/format-patch-doc-test-cleanup'

test cleanup.

* dl/format-patch-doc-test-cleanup:
  t4014: treat rev-list output as the expected value

Merge branch 'js/xdiffi-comment-updates'

Comment update.

* js/xdiffi-comment-updates:
  xdiffi: fix typos and touch up comments

Merge branch 'dl/t0000-skip-test-test'

test update.

* dl/t0000-skip-test-test:
  t0000: cover GIT_SKIP_TESTS blindspots

Merge branch 'tg/range-diff-output-update'

"git range-diff" failed to handle mode-only change, which has been
corrected.

* tg/range-diff-output-update:
  range-diff: don't segfault with mode-only changes

Merge branch 'gs/sq-quote-buf-pretty'

Pretty-printed command line formatter (used in e.g. reporting the
command being run by the tracing API) had a bug that lost an
argument that is an empty string, which has been corrected.

* gs/sq-quote-buf-pretty:
  sq_quote_buf_pretty: don't drop empty arguments

Merge branch 'ew/hashmap'

Code clean-up of the hashmap API, both users and implementation.

* ew/hashmap:
  hashmap_entry: remove first member requirement from docs
  hashmap: remove type arg from hashmap_{get,put,remove}_entry
  OFFSETOF_VAR macro to simplify hashmap iterators
  hashmap: introduce hashmap_free_entries
  hashmap: hashmap_{put,remove} return hashmap_entry *
  hashmap: use *_entry APIs for iteration
  hashmap_cmp_fn takes hashmap_entry params
  hashmap_get{,_from_hash} return "struct hashmap_entry *"
  hashmap: use *_entry APIs to wrap container_of
  hashmap_get_next returns "struct hashmap_entry *"
  introduce container_of macro
  hashmap_put takes "struct hashmap_entry *"
  hashmap_remove takes "const struct hashmap_entry *"
  hashmap_get takes "const struct hashmap_entry *"
  hashmap_add takes "struct hashmap_entry *"
  hashmap_get_next takes "const struct hashmap_entry *"
  hashmap_entry_init takes "struct hashmap_entry *"
  packfile: use hashmap_entry in delta_base_cache_entry
  coccicheck: detect hashmap_entry.hash assignment
  diff: use hashmap_entry_init on moved_entry.ent

Merge branch 'js/trace2-cap-max-output-files'

The trace2 output, when sending them to files in a designated
directory, can populate the directory with too many files; a
mechanism is introduced to set the maximum number of files and
discard further logs when the maximum is reached.

* js/trace2-cap-max-output-files:
  trace2: write discard message to sentinel files
  trace2: discard new traces if target directory has too many files
  docs: clarify trace2 version invariants
  docs: mention trace2 target-dir mode in git-config

Merge branch 'am/t0028-utf16-tests'

Test fixes.

* am/t0028-utf16-tests:
  t0028: add more tests
  t0028: fix test for UTF-16-LE-BOM

Merge branch 'dl/octopus-graph-bug'

"git log --graph" for an octopus merge is sometimes colored
incorrectly, which is demonstrated and documented but not yet
fixed.

* dl/octopus-graph-bug:
  t4214: demonstrate octopus graph coloring failure
  t4214: explicitly list tags in log
  t4214: generate expect in their own test cases
  t4214: use test_merge
  test-lib: let test_merge() perform octopus merges

Merge branch 'en/fast-imexport-nested-tags'

Updates to fast-import/export.

* en/fast-imexport-nested-tags:
  fast-export: handle nested tags
  t9350: add tests for tags of things other than a commit
  fast-export: allow user to request tags be marked with --mark-tags
  fast-export: add support for --import-marks-if-exists
  fast-import: add support for new 'alias' command
  fast-import: allow tags to be identified by mark labels
  fast-import: fix handling of deleted tags
  fast-export: fix exporting a tag and nothing else

Merge branch 'js/azure-pipelines-msvc'

CI updates.

* js/azure-pipelines-msvc:
  ci: also build and test with MS Visual Studio on Azure Pipelines
  ci: really use shallow clones on Azure Pipelines
  tests: let --immediate and --write-junit-xml play well together
  test-tool run-command: learn to run (parts of) the testsuite
  vcxproj: include more generated files
  vcxproj: only copy `git-remote-http.exe` once it was built
  msvc: work around a bug in GetEnvironmentVariable()
  msvc: handle DEVELOPER=1
  msvc: ignore some libraries when linking
  compat/win32/path-utils.h: add #include guards
  winansi: use FLEX_ARRAY to avoid compiler warning
  msvc: avoid using minus operator on unsigned types
  push: do not pretend to return `int` from `die_push_simple()`

Merge branch 'gs/commit-graph-trace-with-cmd'

Dev support.

* gs/commit-graph-trace-with-cmd:
  commit-graph: emit trace2 cmd_mode for each sub-command

Merge branch 'js/fetch-jobs'

"git fetch --jobs=<n>" allowed <n> parallel jobs when fetching
submodules, but this did not apply to "git fetch --multiple" that
fetches from multiple remote repositories.  It now does.

* js/fetch-jobs:
  fetch: let --jobs=<n> parallelize --multiple, too

Merge branch 'en/merge-recursive-cleanup'

The merge-recursive machiery is one of the most complex parts of
the system that accumulated cruft over time.  This large series
cleans up the implementation quite a bit.

* en/merge-recursive-cleanup: (26 commits)
  merge-recursive: fix the fix to the diff3 common ancestor label
  merge-recursive: fix the diff3 common ancestor label for virtual commits
  merge-recursive: alphabetize include list
  merge-recursive: add sanity checks for relevant merge_options
  merge-recursive: rename MERGE_RECURSIVE_* to MERGE_VARIANT_*
  merge-recursive: split internal fields into a separate struct
  merge-recursive: avoid losing output and leaking memory holding that output
  merge-recursive: comment and reorder the merge_options fields
  merge-recursive: consolidate unnecessary fields in merge_options
  merge-recursive: move some definitions around to clean up the header
  merge-recursive: rename merge_options argument to opt in header
  merge-recursive: rename 'mrtree' to 'result_tree', for clarity
  merge-recursive: use common name for ancestors/common/base_list
  merge-recursive: fix some overly long lines
  cache-tree: share code between functions writing an index as a tree
  merge-recursive: don't force external callers to do our logging
  merge-recursive: remove useless parameter in merge_trees()
  merge-recursive: exit early if index != head
  Ensure index matches head before invoking merge machinery, round N
  merge-recursive: remove another implicit dependency on the_repository
  ...

remote-curl: use argv_array in parse_push()

Use argv_array to build an array of strings instead of open-coding it.
This simplifies the code a bit.

We also need to make the specs parameter of push(), push_dav() and
push_git() const to match the argv member of the argv_array.  That's
fine, as all three only actually read from the specs array anyway.

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

column: use utf8_strnwidth() to strip out ANSI color escapes

Make use of utf8_strnwidth()'s feature to skip ANSI escape sequences
instead of open-coding it.  This shortens the code and makes it more
consistent.

This changes the behavior, though: The old code skips all kinds of
Control Sequence Introducer sequences, while utf8_strnwidth() only skips
the Select Graphic Rendition kind, i.e. those ending with "m".  They are
used for specifying color and font attributes like boldness.  The only
other kind of escape sequence we print in Git is Erase in Line, ending
with "K".  That's not used for columnar output, so this difference
actually doesn't matter here.

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

http-push: simplify deleting a list item

The first step for deleting an item from a linked list is to locate the
item preceding it.  Be more careful in release_request() and handle an
empty list.  This only has consequences for invalid delete requests
(removing the same item twice, or deleting an item that was never added
to the list), but simplifies the loop condition as well as the check
after the loop.

Once we found the item's predecessor in the list, update its next
pointer to skip over the item, which removes it from the list.  In other
words: Make the item's successor the successor of its predecessor.
(At this point entry->next == request and prev->next == lock,
respectively.)  This is a bit simpler and saves a pointer dereference.

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

stash: avoid recursive hard reset on submodules

git stash push does not recursively stash submodules, but if
submodule.recurse is set, it may recursively reset --hard them. Having
only the destructive action recurse is likely to be surprising
behaviour, and unlikely to be desirable, so the easiest fix should be to
ensure that the call to git reset --hard never recurses into submodules.

This matches the behavior of check_changes_tracked_files, which ignores
submodules.

Signed-off-by: Jakob Jarmar <jakob@jarmar.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

format-patch: create leading components of output directory

'git format-patch -o <outdir>' did an equivalent of 'mkdir <outdir>'
not 'mkdir -p <outdir>', which is being corrected.

Avoid the usage of 'adjust_shared_perm' on the leading directories which
may have security implications. Achieved by temporarily disabling of
'config.sharedRepository' like 'git init' does.

Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-compat-util: fix documentation syntax

The parameter marker for x was garbled in its introduction in 89c855ed3c
("git-compat-util.h: implement a different ARRAY_SIZE macro for for
safely deriving the size of array", 2015-04-30).

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

utf8: use ARRAY_SIZE() in git_wcwidth()

This macro has been available globally since b4f2a6ac92 ("Use #define
ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))", 2006-03-09), so let's use it.

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

Makefile: respect $(V) in %.cocci.patch target

When the %.cocci.patch target was defined in 63f0a758a0 (add coccicheck
make target, 2016-09-15), it included a mechanism to suppress the noisy
output, similar to the $(QUIET_<x>) family of variables.

In the case where one wants to inspect the output hidden by
$(QUIET_<x>), one could define $(V) for verbose output. In the
%.cocci.patch target, this was not implemented.

Move the output suppression into the $(QUIET_SPATCH) variable which is
used like the other $(QUIET_<x>) variables. While we're at it, change
the number of spaces printed from 5 to 4, like the other variables
there.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pthread.h: manually align parameter lists

In previous patches, extern was mechanically removed from function
declarations without care to formatting, causing parameter lists to be
misaligned. Manually format changed sections such that the parameter
lists are realigned.

Viewing this patch with 'git diff -w' should produce no output.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1308-config-set: fix a test that has a typo

Change test 'find value_list for a key from a configset' to redirect the
result to 'expect' instead of 'except' which was a typo.

With this change, the test case actually fails because it uses
`configset_get_value`. Clearly, this was intended to be
`configset_get_value_multi` since the test expects a list of values
instead of a single value, so let's fix that, too.

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

doc(stash): clarify the description of `save`

The original phrasing of this paragraph made at least one person stumble
over the word "from" (thinking that it was a typo and "from" was
intended), and other readers chimed in, agreeing that it was confusing:
https://public-inbox.org/git/0102016b8d597569-c1f6cfdc-cb45-4428-8737-cb1bc30655d8-000000@eu-west-1.amazonses.com/#t

Let's rewrite that paragraph for clarity.

Inspired-by-a-patch-by: Catalin Criste <cris_linu_w@yahoo.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Eighth batch

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

Merge branch 'dl/rev-list-doc-cleanup'

Doc update.

* dl/rev-list-doc-cleanup:
  git-rev-list.txt: prune options in synopsis

Merge branch 'kt/add-i-progress'

"git add -i" has been taught to show the total number of hunks and
the hunks that has been processed so far when showing prompts.

* kt/add-i-progress:
  add -i: show progress counter in the prompt

Merge branch 'js/stash-apply-in-secondary-worktree'

"git stash apply" in a subdirectory of a secondary worktree failed
to access the worktree correctly, which has been corrected.

* js/stash-apply-in-secondary-worktree:
  stash apply: report status correctly even in a worktree's subdirectory

Merge branch 'rs/dedup-includes'

Code cleanup.

* rs/dedup-includes:
  treewide: remove duplicate #include directives

Merge branch 'js/range-diff-noprefix'

"git range-diff" segfaulted when diff.noprefix configuration was
used, as it blindly expected the patch it internally generates to
have the standard a/ and b/ prefixes.  The command now forces the
internal patch to be built without any prefix, not to be affected
by any end-user configuration.

* js/range-diff-noprefix:
  range-diff: internally force `diff.noprefix=true`

Merge branch 'cb/pcre1-cleanup'

PCRE fixes.

* cb/pcre1-cleanup:
  grep: refactor and simplify PCRE1 support
  grep: make sure NO_LIBPCRE1_JIT disable JIT in PCRE1

Merge branch 'ab/pcre-jit-fixes'

A few simplification and bugfixes to PCRE interface.

* ab/pcre-jit-fixes:
  grep: under --debug, show whether PCRE JIT is enabled
  grep: do not enter PCRE2_UTF mode on fixed matching
  grep: stess test PCRE v2 on invalid UTF-8 data
  grep: create a "is_fixed" member in "grep_pat"
  grep: consistently use "p->fixed" in compile_regexp()
  grep: stop using a custom JIT stack with PCRE v1
  grep: stop "using" a custom JIT stack with PCRE v2
  grep: remove overly paranoid BUG(...) code
  grep: use PCRE v2 for optimized fixed-string search
  grep: remove the kwset optimization
  grep: drop support for \0 in --fixed-strings <pattern>
  grep: make the behavior for NUL-byte in patterns sane
  grep tests: move binary pattern tests into their own file
  grep tests: move "grep binary" alongside the rest
  grep: inline the return value of a function call used only once
  t4210: skip more command-line encoding tests on MinGW
  grep: don't use PCRE2?_UTF8 with "log --encoding=<non-utf8>"
  log tests: test regex backends in "--encode=<enc>" tests

Merge branch 'pw/rebase-i-show-HEAD-to-reword'

"git rebase -i" showed a wrong HEAD while "reword" open the editor.

* pw/rebase-i-show-HEAD-to-reword:
  sequencer: simplify root commit creation
  rebase -i: check for updated todo after squash and reword
  rebase -i: always update HEAD before rewording

Merge branch 'tk/git-svn-trim-author-name'

The author names taken from SVN repositories may have extra leading
or trailing whitespaces, which are now munged away.

* tk/git-svn-trim-author-name:
  git-svn: trim leading and trailing whitespaces in author name

Merge branch 'bc/object-id-part17'

Preparation for SHA-256 upgrade continues.

* bc/object-id-part17: (26 commits)
  midx: switch to using the_hash_algo
  builtin/show-index: replace sha1_to_hex
  rerere: replace sha1_to_hex
  builtin/receive-pack: replace sha1_to_hex
  builtin/index-pack: replace sha1_to_hex
  packfile: replace sha1_to_hex
  wt-status: convert struct wt_status to object_id
  cache: remove null_sha1
  builtin/worktree: switch null_sha1 to null_oid
  builtin/repack: write object IDs of the proper length
  pack-write: use hash_to_hex when writing checksums
  sequencer: convert to use the_hash_algo
  bisect: switch to using the_hash_algo
  sha1-lookup: switch hard-coded constants to the_hash_algo
  config: use the_hash_algo in abbrev comparison
  combine-diff: replace GIT_SHA1_HEXSZ with the_hash_algo
  bundle: switch to use the_hash_algo
  connected: switch GIT_SHA1_HEXSZ to the_hash_algo
  show-index: switch hard-coded constants to the_hash_algo
  blame: remove needless comparison with GIT_SHA1_HEXSZ
  ...

Merge branch 'en/clean-nested-with-ignored'

"git clean" fixes.

* en/clean-nested-with-ignored:
  dir: special case check for the possibility that pathspec is NULL
  clean: fix theoretical path corruption
  clean: rewrap overly long line
  clean: avoid removing untracked files in a nested git repository
  clean: disambiguate the definition of -d
  git-clean.txt: do not claim we will delete files with -n/--dry-run
  dir: add commentary explaining match_pathspec_item's return value
  dir: if our pathspec might match files under a dir, recurse into it
  dir: make the DO_MATCH_SUBMODULE code reusable for a non-submodule case
  dir: also check directories for matching pathspecs
  dir: fix off-by-one error in match_pathspec_item
  dir: fix typo in comment
  t7300: add testcases showing failure to clean specified pathspecs

CODE_OF_CONDUCT: mention individual project-leader emails

It's possible that somebody on the project committee is the subject of a
complaint. In that case, it may be useful to be able to contact the
other members individually, so let's make it clear that's an option.

This also serves to enumerate the set of people on the committee. That
lets you easily _know_ if you're in the situation mentioned above. And
it's just convenient to list who's involved in the process, since the
project committee list is not anywhere else in the repository.

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

add a Code of Conduct document

We've never had a formally written Code of Conduct document. Though it
has been discussed off and on over the years, for the most part the
behavior on the mailing list has been good enough that nobody felt the
need to push one forward.

However, even if there aren't specific problems now, it's a good idea to
have a document:

  - it puts everybody on the same page with respect to expectations.
    This might avoid poor behavior, but also makes it easier to handle
    it if it does happen.

  - it publicly advertises that good conduct is important to us and will
    be enforced, which may make some people more comfortable with
    joining our community

  - it may be a good time to cement our expectations when things are
    quiet, since it gives everybody some distance rather than focusing
    on a current contentious issue

This patch adapts the Contributor Covenant Code of Conduct. As opposed
to writing our own from scratch, this uses common and well-accepted
language, and strikes a good balance between illustrating expectations
and avoiding a laundry list of behaviors. It's also the same document
used by the Git for Windows project.

The text is taken mostly verbatim from:

  https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

I also stole a very nice introductory paragraph from the Git for Windows
version of the file.

There are a few subtle points, though:

  - the document refers to "the project maintainers". For the code, we
    generally only consider there to be one maintainer: Junio C Hamano.
    But for dealing with community issues, it makes sense to involve
    more people to spread the responsibility. I've listed the project
    committee address of git@sfconservancy.org as the contact point.

  - the document mentions banning from the community, both in the intro
    paragraph and in "Our Responsibilities". The exact mechanism here is
    left vague. I can imagine it might start with social enforcement
    (not accepting patches, ignoring emails) and could escalate to
    technical measures if necessary (asking vger admins to block an
    address). It probably make sense _not_ to get too specific at this
    point, and deal with specifics as they come up.

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: CB Bailey <cb@hashpling.org>
Acked-by: Christian Couder <chriscool@tuxfamily.org>
Acked-by: Emily Shaffer <emilyshaffer@google.com>
Acked-by: Garima Singh <garimasigit@gmail.com>
Acked-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Jonathan Tan <jonathantanmy@google.com>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Taylor Blau <me@ttaylorr.com>
Acked-by: Elijah Newren <newren@gmail.com>
Acked-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Acked-by: brian m. carlson <sandals@crustytoothpaste.net>
Acked-by: Derrick Stolee <stolee@gmail.com>
Acked-by: Thomas Gummerer <t.gummerer@gmail.com>
Acked-by: William Baker <williamtbakeremail@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Seventh batch

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

Merge branch 'rs/test-remove-useless-debugging-cat'

Code cleanup.

* rs/test-remove-useless-debugging-cat:
  tests: remove "cat foo" before "test_i18ngrep bar foo"

Merge branch 'pm/p4-auto-delete-named-temporary'

* pm/p4-auto-delete-named-temporary:
  git-p4: auto-delete named temporary file

Merge branch 'rs/convert-fix-utf-without-dash'

The code to skip "UTF" and "UTF-" prefix, when computing an advice
message, did not work correctly when the prefix was "UTF", which
has been fixed.

* rs/convert-fix-utf-without-dash:
  convert: fix handling of dashless UTF prefix in validate_encoding()

Merge branch 'py/git-gui-has-maintainer'

Doc update.

* py/git-gui-has-maintainer:
  Documentation: update the location of the git-gui repo

Merge branch 'ah/cleanups'

Miscellaneous code clean-ups.

* ah/cleanups:
  git_mkstemps_mode(): replace magic numbers with computed value
  wrapper: use a loop instead of repetitive statements
  diffcore-break: use a goto instead of a redundant if statement
  commit-graph: remove a duplicate assignment

Merge branch 'js/diff-rename-force-stable-sort'

The rename detection logic sorts a list of rename source candidates
by similarity to pick the best candidate, which means that a tie
between sources with the same similarity is broken by the original
location in the original candidate list (which is sorted by path).
Force the sorting by similarity done with a stable sort, which is
not promised by system supplied qsort(3), to ensure consistent
results across platforms.

* js/diff-rename-force-stable-sort:
  diffcore_rename(): use a stable sort
  Move git_sort(), a stable sort, into into libgit.a

Merge branch 'js/mingw-spawn-with-spaces-in-path'

Test fix.

* js/mingw-spawn-with-spaces-in-path:
  t0061: fix test for argv[0] with spaces (MINGW only)

Merge branch 'as/shallow-slab-use-fix'

Correct code that tried to reference all entries in a sparse array
of pointers by mistake.

* as/shallow-slab-use-fix:
  shallow.c: don't free unallocated slabs

Merge branch 'sg/name-rev-cutoff-underflow-fix'

Integer arithmetic fix.

* sg/name-rev-cutoff-underflow-fix:
  name-rev: avoid cutoff timestamp underflow

Merge branch 'am/visual-studio-config-fix'

Dev support.

* am/visual-studio-config-fix:
  contrib/buildsystems: fix Visual Studio Debug configuration

xdiffi: fix typos and touch up comments

Inspired by the thoroughly stale https://github.com/git/git/pull/159,
this patch fixes a couple of typos, rewraps and clarifies some comments.

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

t0000: cover GIT_SKIP_TESTS blindspots

Currently, the tests for GIT_SKIP_TESTS do not cover the situation where
we skip an entire test suite. The tests also do not cover the situation
where we have GIT_SKIP_TESTS defined but the test suite does not match.

Add two test cases so we cover this blindspot.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-pack: never fetch when checking exclusions

When building the packfile to be sent, send_pack() is given a list of
remote refs to be used as exclusions. For each ref, it first checks if
the ref exists locally, and if it does, passes it with a "^" prefix to
pack-objects. However, in a partial clone, the check may trigger a lazy
fetch.

The additional commit ancestry information obtained during such fetches
may show that certain objects that would have been sent are already
known to the server, resulting in a smaller pack being sent. But this is
at the cost of fetching from many possibly unrelated refs, and the lazy
fetches do not help at all in the typical case where the client is
up-to-date with the upstream of the branch being pushed.

Ensure that these lazy fetches do not occur.

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

t4014: treat rev-list output as the expected value

In 6bd26f58ea (t4014: use test_line_count() where possible, 2019-08-27),
we converted many test cases to take advantage of the test_line_count()
function. In one conversion, we inverted the expected and actual value
as tested by test_line_count(). Although functionally correct, if
format-patch ever produced incorrect output, the debugging output would
be a bunch of hashes which would be difficult to debug.

Invert the expected and actual values provided to test_line_count() so
that if format-patch produces incorrect output, the debugging output
will be a list of human-readable files instead.

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

range-diff: don't segfault with mode-only changes

In ef283b3699 ("apply: make parse_git_diff_header public", 2019-07-11)
the 'parse_git_diff_header' function was made public and useable by
callers outside of apply.c.

However it was missed that its (then) only caller, 'find_header' did
some error handling, and completing 'struct patch' appropriately.

range-diff then started using this function, and tried to handle this
appropriately itself, but fell short in some cases.  This in turn
would lead to range-diff segfaulting when there are mode-only changes
in a range.

Move the error handling and completing of the struct into the
'parse_git_diff_header' function, so other callers can take advantage
of it.  This fixes the segfault in 'git range-diff'.

Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

transport: push codepath can take arbitrary repository

The previous step added annotations with "the_repository" to various
functions in the push codepath in the transport layer, but they all
can take arbitrary repository pointer, and may be working on a
repository that is not the_repository.  Fix them.

Signed-off-by: Josh Steadmon <steadmon@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sq_quote_buf_pretty: don't drop empty arguments

Empty arguments passed on the command line can be represented by
a '', however sq_quote_buf_pretty was incorrectly dropping these
arguments altogether. Fix this problem by ensuring that such
arguments are emitted as '' instead.

Signed-off-by: Garima Singh <garima.singh@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-recursive: fix the fix to the diff3 common ancestor label

In commit 8e4ec337 ("merge-recursive: fix the diff3 common ancestor
label for virtual commits", 2019-10-01), which was a fix to commit
743474cbfa8b ("merge-recursive: provide a better label for diff3
common ancestor", 2019-08-17), the label for the common ancestor was
changed from always being

         "merged common ancestors"

to instead be based on the number of merge bases and whether the merge
base was a real commit or a virtual one:

    >=2: "merged common ancestors"
      1, via merge_recursive_generic: "constructed merge base"
      1, otherwise: <abbreviated commit hash>
      0: "<empty tree>"

The handling for "constructed merge base" worked by allowing
opt->ancestor to be set in merge_recursive_generic(), so we paid
attention to the setting of that variable in merge_recursive_internal().
Now, for the outer merge, the code flow was simply the following:

ancestor_name = "merged merge bases"
loop over merge_bases: merge_recursive_internal()

The first merge base not needing recursion would determine its own
ancestor_name however necessary and thus run

ancestor_name = $SOMETHING
empty loop over merge_bases...
opt->ancestor = ancestor_name
        merge_trees_internal()

Now, the next set of merge_bases that would need to be merged after this
particular merge had completed would note that opt->ancestor has been
set to something (to a local ancestor_name variable that has since been
popped off the stack), and thus it would run:

... else if (opt->ancestor) {
ancestor_name = opt->ancestor;  /* OOPS! */
        loop over merge_bases: merge_recursive_internal()
        opt->ancestor = ancestor_name
        merge_trees_internal()

This resulted in garbage strings being printed for the virtual merge
bases, which was visible in git.git by just merging commit b744c3af07
into commit 6d8cb22a4f.  There are two ways to fix this: set
opt->ancestor to NULL after using it to avoid re-use, or add a
!opt->priv->call_depth check to the if block for using a pre-defined
opt->ancestor.  Apply both fixes.

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

Sixth batch

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

Merge branch 'bw/submodule-helper-usage-fix'

Typofix.

* bw/submodule-helper-usage-fix:
  builtin/submodule--helper: fix usage string for 'update-clone'

Merge branch 'dl/honor-cflags-in-hdr-check'

Dev support.

* dl/honor-cflags-in-hdr-check:
  ci: run `hdr-check` as part of the `Static Analysis` job
  Makefile: emulate compile in $(HCO) target better
  pack-bitmap.h: remove magic number
  promisor-remote.h: include missing header
  apply.h: include missing header

Merge branch 'cb/do-not-use-test-cmp-with-a'

Test portability fix.

* cb/do-not-use-test-cmp-with-a:
  t4038: Remove non-portable '-a' option passed to test_cmp

Merge branch 'cc/multi-promisor'

Cleanup.

* cc/multi-promisor:
  promisor-remote: skip move_to_tail when no-op
  promisor-remote.h: drop extern from function declaration

Merge branch 'jt/merge-recursive-symlink-is-not-a-dir-in-way'

A bug in merge-recursive code that triggers when a branch with a
symbolic link is merged with a branch that replaces it with a
directory has been fixed.

* jt/merge-recursive-symlink-is-not-a-dir-in-way:
  merge-recursive: symlink's descendants not in way

Merge branch 'ps/my-first-contribution-alphasort'

Docfix.

* ps/my-first-contribution-alphasort:
  doc: MyFirstContribution: fix cmd placement instructions

Merge branch 'sg/travis-help-debug'

Dev support update.

* sg/travis-help-debug:
  travis-ci: do not skip successfully tested trees in debug mode

Merge branch 'rs/alias-use-copy-array'

Code cleanup.

* rs/alias-use-copy-array:
  git: use COPY_ARRAY and MOVE_ARRAY in handle_alias()

Merge branch 'sg/t-helper-gitignore'

Update the way build artifacts in t/helper/ directory are ignored.

* sg/t-helper-gitignore:
  t/helper: ignore only executable files

Merge branch 'cc/svn-fe-py-shebang'

* cc/svn-fe-py-shebang:
  contrib/svn-fe: fix shebang for svnrdump_sim.py

Merge branch 'ah/doc-submodule-ignore-submodules'

Docfix.

* ah/doc-submodule-ignore-submodules:
  doc: fix reference to --ignore-submodules

Merge branch 'rs/nth-switch-code-simplification'

Code simplification.

* rs/nth-switch-code-simplification:
  sha1_name: simplify strbuf handling in interpret_nth_prior_checkout()

Merge branch 'hb/hg-to-git-py3'

The hg-to-git script (in contrib/) has been updated to work with
Python 3.

* hb/hg-to-git-py3:
  hg-to-git: make it compatible with both python3 and python2

Merge branch 'sg/progress-fix'

Regression fix for progress output.

* sg/progress-fix:
  Test the progress display
  Revert "progress: use term_clear_line()"