hashmap_get takes "const struct hashmap_entry *"

This is less error-prone than "const void *" as the compiler
now detects invalid types being passed.

Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

hashmap_add takes "struct hashmap_entry *"

This is less error-prone than "void *" as the compiler now
detects invalid types being passed.

Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

hashmap_get_next takes "const struct hashmap_entry *"

This is less error-prone than "const void *" as the compiler
now detects invalid types being passed.

Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

hashmap_entry_init takes "struct hashmap_entry *"

C compilers do type checking to make life easier for us.  So
rely on that and update all hashmap_entry_init callers to take
"struct hashmap_entry *" to avoid future bugs while improving
safety and readability.

Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

packfile: use hashmap_entry in delta_base_cache_entry

This hashmap_entry_init function is intended to take a
hashmap_entry struct pointer, not a hashmap struct pointer.

This was not noticed because hashmap_entry_init takes a "void *"
arg instead of "struct hashmap_entry *", and the hashmap struct
is larger and can be cast into a hashmap_entry struct without
data corruption.

This has the beneficial side effect of reducing the size of
a delta_base_cache_entry from 104 bytes to 72 bytes on 64-bit
systems.

Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

coccicheck: detect hashmap_entry.hash assignment

Assigning hashmap_entry.hash manually leaves hashmap_entry.next
uninitialized, which can be dangerous once the hashmap_entry is
inserted into a hashmap.   Detect those assignments and use
hashmap_entry_init, instead.

Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: use hashmap_entry_init on moved_entry.ent

Otherwise, the hashmap_entry.next field appears to remain
uninitialized, which can lead to problems when
add_lines_to_move_detection calls hashmap_add.

I found this through manual inspection when converting
hashmap_add callers to take "struct hashmap_entry *".

Signed-off-by: Eric Wong <e@80x24.org>
Reviewed-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: remove "cat foo" before "test_i18ngrep bar foo"

Some tests print a file before searching for a pattern using
test_i18ngrep.  This is useful when debugging tests with --verbose when
the pattern is not found as expected.

Since 63b1a175ee (t: make 'test_i18ngrep' more informative on failure,
2018-02-08) test_i18ngrep already shows the contents of a file that
doesn't match the expected pattern, though.

So don't bother doing the same unconditionally up-front.  The contents
are not interesting if the expected pattern is found, and showing it
twice if it doesn't match is of no use.

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

git-p4: auto-delete named temporary file

Avoid double-open exceptions on Windows platform when
calculating for lfs compressed size threshold
(git-p4.largeFileCompressedThreshold) comparisons.

Take new approach using the NamedTemporaryFile()
file-like object as input to the ZipFile() which
auto-deletes after implicit close leaving with scope.

Original code had double-open exception on Windows
platform because file still open from NamedTemporaryFile()
using generated filename instead of object.

Thanks to Andrey for patiently suggesting several
iterations on this change for avoiding exceptions!

Also print error details after resulting IOError to make
debugging cause of exception less mysterious when it has
nothing to do with "git version recent enough."

Signed-off-by: Philip.McGraw <Philip.McGraw@bentley.com>
Reviewed-by: Andrey Mazo <ahippo@yandex.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fifth batch

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

Merge branch 'cb/skip-utf8-check-with-pcre1'

Make sure the grep machinery does not abort when seeing a payload
that is not UTF-8 even when JIT is not in use with PCRE1.

* cb/skip-utf8-check-with-pcre1:
  grep: skip UTF8 checks explicitly

Merge branch 'ma/user-manual-markup-update'

The markup used in user-manual has been updated to work better with
asciidoctor.

* ma/user-manual-markup-update:
  user-manual.txt: render ASCII art correctly under Asciidoctor
  asciidoctor-extensions.rb: handle "book" doctype in linkgit
  user-manual.txt: change header notation
  user-manual.txt: add missing section label

Merge branch 'bc/doc-use-docbook-5'

Start using DocBook 5 (instead of DocBook 4.5) as Asciidoctor 2.0
no longer works with the older one.

* bc/doc-use-docbook-5:
  Documentation: fix build with Asciidoctor 2

Merge branch 'ma/asciidoctor-more-fixes'

Doc formatting updates.

* ma/asciidoctor-more-fixes:
  gitweb.conf.txt: switch pluses to backticks to help Asciidoctor
  git-merge-index.txt: wrap shell listing in "----"
  git-receive-pack.txt: wrap shell [script] listing in "----"
  git-ls-remote.txt: wrap shell listing in "----"
  Documentation: wrap config listings in "----"
  git-merge-base.txt: render indentations correctly under Asciidoctor
  Documentation: wrap blocks with "--"

Merge branch 'ma/asciidoctor-refmiscinfo'

Update support for Asciidoctor documentation toolchain.

* ma/asciidoctor-refmiscinfo:
  doc-diff: replace --cut-header-footer with --cut-footer
  asciidoctor-extensions: provide `<refmiscinfo/>`
  Doc/Makefile: give mansource/-version/-manual attributes

Merge branch 'am/mailmap-andrey-mazo'

* am/mailmap-andrey-mazo:
  .mailmap: update email address of Andrey Mazo

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

* jc/git-gui-has-maintainer:
  SubmittingPatches: git-gui has a new maintainer

git-rev-list.txt: prune options in synopsis

The synopsis section in git-rev-list.txt has grown to be a huge list
that probably needs its own synopsis. Since the list is huge, users may
be given the false impression that the list is complete, however it is
not. It is missing many of the available options.

Since the list of options in the synopsis is not only annoying but
actively harmful, replace it with `[<options>]` so users know to
explicitly look through the documentation for further information.

While we're at it, update the optional path notation so that it is more
modern.

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

Documentation: update the location of the git-gui repo

Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

convert: fix handling of dashless UTF prefix in validate_encoding()

Strip "UTF" and an optional dash from the start of 'upper' without
passing a NULL pointer to skip_prefix() in the second call, as it cannot
handle that.

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

ci: also build and test with MS Visual Studio on Azure Pipelines

... because we can, now. Technically, we actually build using `MSBuild`,
which is however pretty close to building interactively in Visual
Studio.

As there is no convenient way to run Git's test suite in Visual Studio,
we unpack a Portable Git to run it, using the just-added test helper to
allow running test scripts in parallel.

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

ci: really use shallow clones on Azure Pipelines

This was a left-over from the previous YAML schema, and it no longer
works. The problem was noticed while editing `azure-pipelines.yml` in VS
Code with the very helpful "Azure Pipelines" extension (syntax
highlighting and intellisense for `azure-pipelines.yml`...).

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

tests: let --immediate and --write-junit-xml play well together

When the `--immediate` option is in effect, any test failure will
immediately exit the test script. Together with `--write-junit-xml`, we
will want the JUnit-style `.xml` file to be finalized (and not leave the
XML incomplete). Let's make it so.

This comes in particularly handy when trying to debug via Azure
Pipelines, where the JUnit-style XML is consumed to present the test
results in an informative and helpful way.

While at it, also handle the `error()` code path.

The only remaining code path that sets `GIT_EXIT_OK` happens whenever
the trash directory could not be set up, i.e. long before the JUnit XML
was written, therefore we should _not_ try to finalize that XML in that
case.

It is tempting to change the `immediate` code path to just hand off to
`error`, simplifying the code in the process. That would, however,
result in a change of behavior (an additional error message) in the test
suite, which is outside of the purview of the current patch series: its
goal is to allow building Git with Visual Studio and testing it with a
portable version of Git for Windows.

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

test-tool run-command: learn to run (parts of) the testsuite

Git for Windows jumps through hoops to provide a development environment
that allows to build Git and to run its test suite. To that end, an
entire MSYS2 system, including GNU make and GCC is offered as "the Git
for Windows SDK". It does come at a price: an initial download of said
SDK weighs in with several hundreds of megabytes, and the unpacked SDK
occupies ~2GB of disk space.

A much more native development environment on Windows is Visual Studio.
To help contributors use that environment, we already have a Makefile
target `vcxproj` that generates a commit with project files (and other
generated files), and Git for Windows' `vs/master` branch is
continuously re-generated using that target.

The idea is to allow building Git in Visual Studio, and to run
individual tests using a Portable Git.

The one missing thing is a way to run the entire test suite: neither
`make` nor `prove` are required to run Git, therefore Git for Windows
does not support those commands in the Portable Git.

To help with that, add a simple test helper that exercises the
`run_processes_parallel()` function to allow for running test scripts in
parallel (which is really necessary, especially on Windows, as Git's
test suite takes such a long time to run).

This will also come in handy for the upcoming change to our Azure
Pipeline: we will use this helper in a Portable Git to test the Visual
Studio build of Git.

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

vcxproj: include more generated files

In the CI builds, we bundle all generated files into a so-called
artifacts `.tar` file, so that the test phase can fan out into multiple
parallel builds.

This patch makes sure that all files are included in the `vcxproj`
target which are needed for that artifacts `.tar` file.

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

vcxproj: only copy `git-remote-http.exe` once it was built

In b18ae14a8f6 (vcxproj: also link-or-copy builtins, 2019-07-29), we
started to copy or hard-link the built-ins as a post-build step of the
`git` project.

At the same time, we tried to copy or hard-link `git-remote-http.exe`,
but it is quite possible that it was not built at that time.

Let's move that latter task into a post-install step of the
`git-remote-http` project instead.

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

msvc: work around a bug in GetEnvironmentVariable()

The return value of that function is 0 both for variables that are
unset, as well as for variables whose values are empty. To discern those
two cases, one has to call `GetLastError()`, whose return value is
`ERROR_ENVVAR_NOT_FOUND` and `ERROR_SUCCESS`, respectively.

Except that it is not actually set to `ERROR_SUCCESS` in the latter
case, apparently, but the last error value seems to be simply unchanged.

To work around this, let's just re-set the last error value just before
inspecting the environment variable.

This fixes a problem that triggers failures in t3301-notes.sh (where we
try to override config settings by passing empty values for certain
environment variables).

This problem is hidden in the MINGW build by the fact that older
MSVC runtimes (such as the one used by MINGW builds) have a `calloc()`
that re-sets the last error value in case of success, while newer
runtimes set the error value only if `NULL` is returned by that
function.

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

msvc: handle DEVELOPER=1

We frequently build Git using the `DEVELOPER=1` make setting as a
shortcut to enable all kinds of more stringent compiler warnings.

Those compiler warnings are relatively specific to GCC, though, so let's
try our best to translate them to the equivalent options to pass to MS
Visual C++'s `cl.exe`.

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

msvc: ignore some libraries when linking

To build with MSVC, we "translate" GCC options to MSVC options, and part
of those options refer to the libraries to link into the final
executable. Currently, this part looks somewhat like this on Windows:

-lcurl -lnghttp2 -lidn2 -lssl -lcrypto -lssl -lcrypto -lgdi32
-lcrypt32 -lwldap32 -lz -lws2_32 -lexpat

Some of those are direct dependencies (such as curl and ssl) and others
are indirect (nghttp2 and idn2, for example, are dependencies of curl,
but need to be linked in for reasons).

We already handle the direct dependencies, e.g. `-liconv` is already
handled as adding `libiconv.lib` to the list of libraries to link
against.

Let's just ignore the remaining `-l*` options so that MSVC does not have
to warn us that it ignored e.g. the `/lnghttp2` option. We do that by
extending the clause that already "eats" the `-R*` options to also eat
the `-l*` options.

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

compat/win32/path-utils.h: add #include guards

This adds the common guards that allow headers to be #include'd multiple
times.

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

winansi: use FLEX_ARRAY to avoid compiler warning

MSVC would complain thusly:

    C4200: nonstandard extension used: zero-sized array in struct/union

Let's just use the `FLEX_ARRAY` constant that we introduced for exactly
this type of scenario.

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

msvc: avoid using minus operator on unsigned types

MSVC complains about this with `-Wall`, which can be taken as a sign
that this is indeed a real bug. The symptom is:

C4146: unary minus operator applied to unsigned type, result
still unsigned

Let's avoid this warning in the minimal way, e.g. writing `-1 -
<unsigned value>` instead of `-<unsigned value> - 1`.

Note that the change in the `estimate_cache_size()` function is
needed because MSVC considers the "return type" of the `sizeof()`
operator to be `size_t`, i.e. unsigned, and therefore it cannot be
negated using the unary minus operator.

Even worse, that arithmetic is doing extra work, in vain. We want to
calculate the entry extra cache size as the difference between the
size of the `cache_entry` structure minus the size of the
`ondisk_cache_entry` structure, padded to the appropriate alignment
boundary.

To that end, we start by assigning that difference to the `per_entry`
variable, and then abuse the `len` parameter of the
`align_padding_size()` macro to take the negative size of the ondisk
entry size. Essentially, we try to avoid passing the already calculated
difference to that macro by passing the operands of that difference
instead, when the macro expects operands of an addition:

#define align_padding_size(size, len) \
((size + (len) + 8) & ~7) - (size + len)

Currently, we pass A and -B to that macro instead of passing A - B and
0, where A - B is already stored in the `per_entry` variable, ready to
be used.

This is neither necessary, nor intuitive. Let's fix this, and have code
that is both easier to read and that also does not trigger MSVC's
warning.

While at it, we take care of reporting overflows (which are unlikely,
but hey, defensive programming is good!).

We _also_ take pains of casting the unsigned value to signed: otherwise,
the signed operand (i.e. the `-1`) would be cast to unsigned before
doing the arithmetic.

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

stash apply: report status correctly even in a worktree's subdirectory

When Git wants to spawn a child Git process inside a worktree's
subdirectory while `GIT_DIR` is set, we need to take care of specifying
the work tree's top-level directory explicitly because it cannot be
discovered: the current directory is _not_ the top-level directory of
the work tree, and neither is it inside the parent directory of
`GIT_DIR`.

This fixes the problem where `git stash apply` would report pretty much
everything deleted or untracked when run inside a worktree's
subdirectory.

To make sure that we do not introduce the "reverse problem", i.e. when
`GIT_WORK_TREE` is defined but `GIT_DIR` is not, we simply make sure
that both are set.

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

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

So far, `--jobs=<n>` only parallelizes submodule fetches/clones, not
`--multiple` fetches, which is unintuitive, given that the option's name
does not say anything about submodules in particular.

Let's change that. With this patch, also fetches from multiple remotes
are parallelized.

For backwards-compatibility (and to prepare for a use case where
submodule and multiple-remote fetches may need different parallelization
limits), the config setting `submodule.fetchJobs` still only controls
the submodule part of `git fetch`, while the newly-introduced setting
`fetch.parallel` controls both (but can be overridden for submodules
with `submodule.fetchJobs`).

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

trace2: write discard message to sentinel files

Add a new "discard" event type for trace2 event destinations. When the
trace2 file count check creates a sentinel file, it will include the
normal trace2 output in the sentinel, along with this new discard
event.

Writing this message into the sentinel file is useful for tracking how
often the file count check triggers in practice.

Bump up the event format version since we've added a new event type.

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

trace2: discard new traces if target directory has too many files

trace2 can write files into a target directory. With heavy usage, this
directory can fill up with files, causing difficulty for
trace-processing systems.

This patch adds a config option (trace2.maxFiles) to set a maximum
number of files that trace2 will write to a target directory. The
following behavior is enabled when the maxFiles is set to a positive
integer:
  When trace2 would write a file to a target directory, first check
  whether or not the traces should be discarded. Traces should be
  discarded if:
    * there is a sentinel file declaring that there are too many files
    * OR, the number of files exceeds trace2.maxFiles.
  In the latter case, we create a sentinel file named git-trace2-discard
  to speed up future checks.

The assumption is that a separate trace-processing system is dealing
with the generated traces; once it processes and removes the sentinel
file, it should be safe to generate new trace files again.

The default value for trace2.maxFiles is zero, which disables the file
count check.

The config can also be overridden with a new environment variable:
GIT_TRACE2_MAX_FILES.

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

t4214: demonstrate octopus graph coloring failure

The graph coloring logic for octopus merges currently has a bug. This
can be seen git.git with 74c7cfa875 (Merge of
http://members.cox.net/junkio/git-jc.git, 2005-05-05), whose second
child is 211232bae6 (Octopus merge of the following five patches.,
2005-05-05).

If one runs

git log --graph 74c7cfa875

one can see that the octopus merge is colored incorrectly. In
particular, the horizontal dashes are off by one color. Each horizontal
dash should be the color of the line to their bottom-right. Instead, they
are currently the color of the line to their bottom.

Demonstrate this breakage with a few sets of test cases. These test
cases should show not only simple cases of the bug occuring but trickier
situations that may not be handled properly in any attempt to fix the
bug.

While we're at it, include a passing test case as a canary in case an
attempt to fix the bug breaks existing operation.

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

t4214: explicitly list tags in log

In a future test case, we will be extending the commit graph. As a
result, explicitly list the tags that will generate the graph so that
when future additions are made, the current graph illustrations won't be
affected.

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

t4214: generate expect in their own test cases

Before, the expect files of the test case were being generated in the
setup method. However, it would make more sense to generate these files
within the test cases that actually use them so that it's obvious to
future readers where the expected values are coming from.

Move the generation of the expect files in their own respective test
cases.

While we're at it, we want to establish a pattern in this test suite
that, firstly, a non-colored test case is given then, immediately after,
the colored version is given.

Switch test cases "log --graph with tricky octopus merge, no color" and
"log --graph with tricky octopus merge with colors" so that the "no
color" version appears first.

This patch is best viewed with `--color-moved`.

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

t4214: use test_merge

In the previous commit, we extended test_merge() so that it could
perform octopus merges. Now that the restriction is lifted, use
test_merge() to perform the octopus merge instead of manually
duplicating test_merge() functionality.

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

test-lib: let test_merge() perform octopus merges

Currently test_merge() only allows developers to merge in one branch.
However, this restriction is artificial and there is no reason why it
needs to be this way.

Extend test_merge() to allow the specification of multiple branches so
that octopus merges can be performed.

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

docs: clarify trace2 version invariants

Make it explicit that we always want trace2 "version" events to be the
first event of any trace session. Also list the changes that would or
would not cause the EVENT format version field to be incremented.

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

docs: mention trace2 target-dir mode in git-config

Move the description of trace2's target-directory behavior into the
shared trace2-target-values file so that it is included in both the
git-config and api-trace2 docs. Leave the SID discussion only in
api-trace2 since it's a technical detail.

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

treewide: remove duplicate #include directives

Found with "git grep '^#include ' '*.c' | sort | uniq -d".

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

push: do not pretend to return `int` from `die_push_simple()`

This function is marked as `NORETURN`, and it indeed does not want to
return anything. So let's not declare it with the return type `int`.
This fixes the following warning when building with MSVC:

C4646: function declared with 'noreturn' has non-void return type

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

fast-export: handle nested tags

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

t9350: add tests for tags of things other than a commit

Multiple changes here:
  * add a test for a tag of a blob
  * add a test for a tag of a tag of a commit
  * add a comment to the tests for (possibly nested) tags of trees,
    making it clear that these tests are doing much less than you might
    expect

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

fast-export: allow user to request tags be marked with --mark-tags

Add a new option, --mark-tags, which will output mark identifiers with
each tag object.  This improves the incremental export story with
--export-marks since it will allow us to record that annotated tags have
been exported, and it is also needed as a step towards supporting nested
tags.

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

fast-export: add support for --import-marks-if-exists

fast-import has support for both an --import-marks flag and an
--import-marks-if-exists flag; the latter of which will not die() if the
file does not exist.  fast-export only had support for an --import-marks
flag; add an --import-marks-if-exists flag for consistency.

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

fast-import: add support for new 'alias' command

fast-export and fast-import have nice --import-marks flags which allow
for incremental migrations.  However, if there is a mark in
fast-export's file of marks without a corresponding mark in the one for
fast-import, then we run the risk that fast-export tries to send new
objects relative to the mark it knows which fast-import does not,
causing fast-import to fail.

This arises in practice when there is a filter of some sort running
between the fast-export and fast-import processes which prunes some
commits programmatically.  Provide such a filter with the ability to
alias pruned commits to their most recent non-pruned ancestor.

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

fast-import: allow tags to be identified by mark labels

Mark identifiers are used in fast-export and fast-import to provide a
label to refer to earlier content.  Blobs are given labels because they
need to be referenced in the commits where they first appear with a
given filename, and commits are given labels because they can be the
parents of other commits.  Tags were never given labels, probably
because they were viewed as unnecessary, but that presents two problems:

   1. It leaves us without a way of referring to previous tags if we
      want to create a tag of a tag (or higher nestings).
   2. It leaves us with no way of recording that a tag has already been
      imported when using --export-marks and --import-marks.

Fix these problems by allowing an optional mark label for tags.

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

fast-import: fix handling of deleted tags

If our input stream includes a tag which is later deleted, we were not
properly deleting it.  We did have a step which would delete it, but we
left a tag in the tag list noting that it needed to be updated, and the
updating of annotated tags occurred AFTER ref deletion.  So, when we
record that a tag needs to be deleted, also remove it from the list of
annotated tags to update.

While this has likely been something that has not happened in practice,
it will come up more in order to support nested tags.  For nested tags,
we either need to give temporary names to the intermediate tags and then
delete them, or else we need to use the final name for the intermediate
tags.  If we use the final name for the intermediate tags, then in order
to keep the sanity check that someone doesn't try to update the same tag
twice, we need to delete the ref after creating the intermediate tag.
So, either way nested tags imply the need to delete temporary inner tag
references.

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

add -i: show progress counter in the prompt

Report the current hunk count and total number of hunks for the
current file in the prompt.  Also adjust the expected output in
some tests to match.

Signed-off-by: Kunal Tyagi <tyagi.kunal@live.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'bw/diff3-conflict-style'

git-gui now highlights diff3 style conflicts properly. As an auxiliary
change, querying a path's attribute is done via the existing interface
instead of hand-rolling the code.

* bw/diff3-conflict-style:
  git-gui: support for diff3 conflict style
  git-gui: use existing interface to query a path's attribute

git-gui: support for diff3 conflict style

This adds highlight support for the diff3 conflict style.

The common pre-image will be reversed to --, because it has been removed
and replaced with ours or theirs side respectively.

Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>

range-diff: internally force `diff.noprefix=true`

When parsing the diffs, `range-diff` expects to see the prefixes `a/`
and `b/` in the diff headers.

These prefixes can be forced off via the config setting
`diff.noprefix=true`. As `range-diff` is not prepared for that
situation, this will cause a segmentation fault.

Let's avoid that by passing the `--no-prefix` option to the `git log`
process that generates the diffs that `range-diff` wants to parse.
And of course expect the output to have no prefixes, then.

Reported-by: Michal Suchánek <msuchanek@suse.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ci: run `hdr-check` as part of the `Static Analysis` job

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

push: add trace2 instrumentation

Add trace2 regions in transport.c and builtin/push.c to better track
time spent in various phases of pushing:

* Listing refs
* Checking submodules
* Pushing submodules
* Pushing refs

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

fetch: add trace2 instrumentation

Add trace2 regions to fetch-pack.c and builtins/fetch.c to better track
time spent in the various phases of a fetch:

* listing refs
* negotiation for protocol versions v0-v2
* fetching refs
* consuming refs

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

git_mkstemps_mode(): replace magic numbers with computed value

The magic number "6" appears several times in the function, and is
related to the size of the "XXXXXX" string we expect to find in the
template. Let's pull that "XXXXXX" into a constant array, whose size we
can get at compile time with ARRAY_SIZE().

Note that we probably can't just change this value, since callers will
be feeding us a certain number of X's, but it hopefully makes the
function itself easier to follow.

While we're here, let's do the same with the "letters" array (which we
_could_ modify if we wanted to include more characters).

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

git-gui: use existing interface to query a path's attribute

Replace the hand-coded call to git check-attr with the already provided one.

Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>

Merge branch 'js/git-bash-if-available'

git-gui will now use git-bash instead of bash on Windows, if it is
available.

* js/git-bash-if-available:
  git-gui (Windows): use git-bash.exe if it is available

commit-graph: emit trace2 cmd_mode for each sub-command

Emit trace2_cmd_mode() messages for each commit-graph
sub-command.

The commit graph commands were in flux when trace2 was
making it's way to git. Now that we have enough sub-commands
in commit-graph, we can label the various modes within them.
Distinguishing between read, write and verify is a great
start.

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

t0061: fix test for argv[0] with spaces (MINGW only)

The test was originally designed for the case where user reported
that setting GIT_SSH to a .bat file with spaces in path fails on
Windows: https://github.com/git-for-windows/git/issues/692

The test has two different problems:

1. It succeeds with AND without fix eb7c7863 that addressed user's
   problem. This happens because the core problem was misunderstood,
   leading to conclusion that git is unable to start any programs with
   spaces in path on Win7. But in fact
     a) Bug only affected cmd.exe scripts, such as .bat scripts
     b) Bug only happened when cmd.exe received at least two quoted args
     c) Bug happened on any Windows (verified on Win10).
   Therefore, correct test must involve .bat script and two quoted args.
2. In Visual Studio build, it fails to run, because 'test-fake-ssh.exe'
   is copied away from its dependencies 'libiconv.dll' and 'zlib1.dll'.

Fix both problems by using .bat script instead of 'test-fake-ssh.exe'.
NOTE: With this change, the test now correctly fails without eb7c7863.

Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

wrapper: use a loop instead of repetitive statements

A check into the history of this code revealed no particular reason for
the code to be written in this way. All popular compilers are capable of
unrolling loops if it benefits performance, and once this code is
replaced with a loop, the magic number 6 used in multiple places in this
function can be replaced with a named constant.

Reviewed-by: Derrick Stolee <stolee@gmail.com>
Reviewed-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diffcore-break: use a goto instead of a redundant if statement

The condition "if (q->nr <= j)" checks whether the loop exited normally
or via a break statement. Avoid this check by replacing the jump out of
the inner loop with a jump to the end of the outer loop, which makes it
obvious that diff_q is not executed when the peer survives.

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit-graph: remove a duplicate assignment

Leave the variable 'g' uninitialized before it is set just before its
first use in front of a loop, which is a much more appropriate place to
indicate what it is used for.

Also initialize the variable 'num_commits' just before the loop instead
of at the beginning of the function for the same reason.

Reviewed-by: Derrick Stolee <stolee@gmail.com>
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

shallow.c: don't free unallocated slabs

Fix possible segfault when cloning a submodule shallow.

Signed-off-by: Ali Utku Selen <auselen@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-recursive: fix the diff3 common ancestor label for virtual commits

In 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:

    >=2: "merged common ancestors"
      1: <abbreviated commit hash>
      0: "<empty tree>"

Unfortunately, this did not take into account that when we have a single
merge base, that merge base could be fake or constructed.  In such
cases, this resulted in a label of "00000000".  Of course, the previous
label of "merged common ancestors" was also misleading for this case.
Since we have an API that is explicitly about creating fake merge base
commits in merge_recursive_generic(), we should provide a better label
when using that API with one merge base.  So, when
merge_recursive_generic() is called with one merge base, set the label
to:

         "constructed merge base"

Note that callers of merge_recursive_generic() include the builtin
commands git-am (in combination with git apply --build-fake-ancestor),
git-merge-recursive, and git-stash.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

promisor-remote: skip move_to_tail when no-op

Previously, when promisor_remote_move_to_tail() is called for a
promisor_remote which is currently the final element in promisors, a
cycle is created in the promisors linked list. This cycle leads to a
double free later on in promisor_remote_clear() when the final element
of the promisors list is removed: promisors is set to promisors->next (a
no-op, as promisors->next == promisors); the previous value of promisors
is free()'d; then the new value of promisors (which is equal to the
previous value of promisors) is also free()'d. This double-free error
was unrecoverable for the user without removing the filter or re-cloning
the repo and hoping to miss this edge case.

Now, when promisor_remote_move_to_tail() would be a no-op, just do a
no-op. In cases of promisor_remote_move_to_tail() where r is not already
at the tail of the list, it works as before.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
Acked-by: Christian Couder <christian.couder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diffcore_rename(): use a stable sort

During Git's rename detection, the file names are sorted. At the moment,
this job is performed by `qsort()`. As that function is not guaranteed
to implement a stable sort algorithm, this can lead to inconsistent
and/or surprising behavior: a rename might be detected differently
depending on the platform where Git was run.

The `qsort()` in MS Visual C's runtime does _not_ implement a stable
sort algorithm, and it even leads to an inconsistency leading to a test
failure in t3030.35 "merge-recursive remembers the names of all base
trees": a different code path than on Linux is taken in the rename
detection of an ambiguous rename between either `e` to `a` or
`a~Temporary merge branch 2_0` to `a` during a recursive merge,
unexpectedly resulting in a clean merge.

Let's use the stable sort provided by `git_stable_qsort()` to avoid this
inconsistency.

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

Move git_sort(), a stable sort, into into libgit.a

The `qsort()` function is not guaranteed to be stable, i.e. it does not
promise to maintain the order of items it is told to consider equal. In
contrast, the `git_sort()` function we carry in `compat/qsort.c` _is_
stable, by virtue of implementing a merge sort algorithm.

In preparation for using a stable sort in Git's rename detection, move
the stable sort into `libgit.a` so that it is compiled in
unconditionally, and rename it to `git_stable_qsort()`.

Note: this also makes the hack obsolete that was introduced in
fe21c6b285d (mingw: reencode environment variables on the fly (UTF-16
<-> UTF-8), 2018-10-30), where we included `compat/qsort.c` directly in
`compat/mingw.c` to use the stable sort.

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

dir: special case check for the possibility that pathspec is NULL

Commits 404ebceda01c ("dir: also check directories for matching
pathspecs", 2019-09-17) and 89a1f4aaf765 ("dir: if our pathspec might
match files under a dir, recurse into it", 2019-09-17) added calls to
match_pathspec() and do_match_pathspec() passing along their pathspec
parameter.  Both match_pathspec() and do_match_pathspec() assume the
pathspec argument they are given is non-NULL.  It turns out that
unpack-tree.c's verify_clean_subdirectory() calls read_directory() with
pathspec == NULL, and it is possible on case insensitive filesystems for
that NULL to make it to these new calls to match_pathspec() and
do_match_pathspec().  Add appropriate checks on the NULLness of pathspec
to avoid a segfault.

In case the negation throws anyone off (one of the calls was to
do_match_pathspec() while the other was to !match_pathspec(), yet no
negation of the NULLness of pathspec is used), there are two ways to
understand the differences:
  * The code already handled the pathspec == NULL cases before this
    series, and this series only tried to change behavior when there was
    a pathspec, thus we only want to go into the if-block if pathspec is
    non-NULL.
  * One of the calls is for whether to recurse into a subdirectory, the
    other is for after we've recursed into it for whether we want to
    remove the subdirectory itself (i.e. the subdirectory didn't match
    but something under it could have).  That difference in situation
    leads to the slight differences in logic used (well, that and the
    slightly unusual fact that we don't want empty pathspecs to remove
    untracked directories by default).

Denton found and analyzed one issue and provided the patch for the
match_pathspec() call, SZEDER figured out why the issue only reproduced
for some folks and not others and provided the testcase, and I looked
through the remainder of the series and noted the do_match_pathspec()
call that should have the same check.

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

git-gui (Windows): use git-bash.exe if it is available

Git for Windows 2.x ships with an executable that starts the Git Bash
with all the environment variables and what not properly set up. It is
also adjusted according to the Terminal emulator option chosen when
installing Git for Windows (while `bash.exe --login -i` would always
launch with Windows' default console).

So let's use that executable (usually C:\Program Files\Git\git-bash.exe)
instead of `bash.exe --login -i` if its presence was detected.

This fixes https://github.com/git-for-windows/git/issues/490

Signed-off-by: Thomas Kläger <thomas.klaeger@10a.ch>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>

Fourth batch

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

Merge branch 'ds/commit-graph-on-fetch'

A configuration variable tells "git fetch" to write the commit
graph after finishing.

* ds/commit-graph-on-fetch:
  fetch: add fetch.writeCommitGraph config setting

Merge branch 'bw/rebase-autostash-keep-current-branch'

"git rebase --autostash <upstream> <branch>", when <branch> is
different from the current branch, incorrectly moved the tip of the
current branch, which has been corrected.

* bw/rebase-autostash-keep-current-branch:
  builtin/rebase.c: Remove pointless message
  builtin/rebase.c: make sure the active branch isn't moved when autostashing

Merge branch 'ds/include-exclude'

The internal code originally invented for ".gitignore" processing
got reshuffled and renamed to make it less tied to "excluding" and
stress more that it is about "matching", as it has been reused for
things like sparse checkout specification that want to check if a
path is "included".

* ds/include-exclude:
  unpack-trees: rename 'is_excluded_from_list()'
  treewide: rename 'exclude' methods to 'pattern'
  treewide: rename 'EXCL_FLAG_' to 'PATTERN_FLAG_'
  treewide: rename 'struct exclude_list' to 'struct pattern_list'
  treewide: rename 'struct exclude' to 'struct path_pattern'

Merge branch 'jh/trace2-pretty-output'

Output from trace2 subsystem is formatted more prettily now.

* jh/trace2-pretty-output:
  trace2: cleanup whitespace in perf format
  trace2: cleanup whitespace in normal format
  quote: add sq_append_quote_argv_pretty()
  trace2: trim trailing whitespace in normal format error message
  trace2: remove dead code in maybe_add_string_va()
  trace2: trim whitespace in region messages in perf target format
  trace2: cleanup column alignment in perf target format

Merge branch 'dl/rebase-i-keep-base'

"git rebase --keep-base <upstream>" tries to find the original base
of the topic being rebased and rebase on top of that same base,
which is useful when running the "git rebase -i" (and its limited
variant "git rebase -x").

The command also has learned to fast-forward in more cases where it
can instead of replaying to recreate identical commits.

* dl/rebase-i-keep-base:
  rebase: teach rebase --keep-base
  rebase tests: test linear branch topology
  rebase: fast-forward --fork-point in more cases
  rebase: fast-forward --onto in more cases
  rebase: refactor can_fast_forward into goto tower
  t3432: test for --no-ff's interaction with fast-forward
  t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests
  t3432: test rebase fast-forward behavior
  t3431: add rebase --fork-point tests

Merge branch 'sg/clean-nested-repo-with-ignored'

A bug documentation.

* sg/clean-nested-repo-with-ignored:
  t7300-clean: demonstrate deleting nested repo with an ignored file breakage

Merge branch 'dl/complete-cherry-pick-revert-skip'

The command line completion support (in contrib/) learned about the
"--skip" option of "git revert" and "git cherry-pick".

* dl/complete-cherry-pick-revert-skip:
  status: mention --skip for revert and cherry-pick
  completion: add --skip for cherry-pick and revert
  completion: merge options for cherry-pick and revert

Merge branch 'dl/use-sq-from-test-lib'

Code cleanup.

* dl/use-sq-from-test-lib:
  t: use common $SQ variable

Merge branch 'jk/misc-uninitialized-fixes'

Various fixes to codepaths gcc 9 had trouble following dataflow.

* jk/misc-uninitialized-fixes:
  pack-objects: drop packlist index_pos optimization
  test-read-cache: drop namelen variable
  diff-delta: set size out-parameter to 0 for NULL delta
  bulk-checkin: zero-initialize hashfile_checkpoint
  pack-objects: use object_id in packlist_alloc()
  git-am: handle missing "author" when parsing commit

Merge branch 'sg/git-test-boolean'

Fix an earlier regression in the test suite, which mistakenly
stopped running HTTPD tests.

* sg/git-test-boolean:
  ci: restore running httpd tests
  t/lib-git-svn.sh: check GIT_TEST_SVN_HTTPD when running SVN HTTP tests

Merge branch 'rs/get-tagged-oid'

Code cleanup.

* rs/get-tagged-oid:
  use get_tagged_oid()
  tag: factor out get_tagged_oid()

Merge branch 'en/filter-branch-deprecation'

Start discouraging the use of "git filter-branch".

* en/filter-branch-deprecation:
  t9902: use a non-deprecated command for testing
  Recommend git-filter-repo instead of git-filter-branch
  t6006: simplify, fix, and optimize empty message test

Merge branch 'en/merge-options-ff-and-friends'

Doc update.

* en/merge-options-ff-and-friends:
  merge-options.txt: clarify meaning of various ff-related options

Merge branch 'tg/push-all-in-mirror-forbidden'

Fix an earlier regression to "git push --all" which should have
been forbidden when the target remote repository is set to be a
mirror.

* tg/push-all-in-mirror-forbidden:
  push: disallow --all and refspecs when remote.<name>.mirror is set

Merge branch 'dt/remote-helper-doc-re-lock-option'

Doc update.

* dt/remote-helper-doc-re-lock-option:
  clarify documentation for remote helpers

Merge branch 'rs/help-unknown-ref-does-not-return'

Code cleanup.

* rs/help-unknown-ref-does-not-return:
  help: make help_unknown_ref() NORETURN

Merge branch 'nd/switch-and-restore'

Resurrect a performance hack.

* nd/switch-and-restore:
  checkout: add simple check for 'git checkout -b'

Merge branch 'tb/file-url-to-unc-path'

Windows update.

* tb/file-url-to-unc-path:
  mingw: support UNC in git clone file://server/share/repo

Merge branch 'js/gitdir-at-unc-root'

On Windows, the root level of UNC share is now allowed to be used
just like any other directory.

* js/gitdir-at-unc-root:
  setup_git_directory(): handle UNC root paths correctly
  Fix .git/ discovery at the root of UNC shares
  setup_git_directory(): handle UNC paths correctly

Merge branch 'ar/mingw-run-external-with-non-ascii-path'

Windows update.

* ar/mingw-run-external-with-non-ascii-path:
  mingw: fix launching of externals from Unicode paths

Merge branch 'rs/parse-tree-indirect'

Code cleanup.

* rs/parse-tree-indirect:
  tree: simplify parse_tree_indirect()

Merge branch 'jk/fast-import-history-bugfix'

The memory ownership model of the "git fast-import" got
straightened out.

* jk/fast-import-history-bugfix:
  fast-import: duplicate into history rather than passing ownership
  fast-import: duplicate parsed encoding string

Merge branch 'mh/notes-duplicate-entries'

A few implementation fixes in the notes API.

* mh/notes-duplicate-entries:
  notes: avoid potential use-after-free during insertion
  notes: avoid leaking duplicate entries

Merge branch 'tb/banned-vsprintf-namefix'

Error message fix.

* tb/banned-vsprintf-namefix:
  banned.h: fix vsprintf()'s ban message

Merge branch 'mh/release-commit-memory-fix'

Leakfix.

* mh/release-commit-memory-fix:
  commit: free the right buffer in release_commit_memory