archive-tar: turn length miscalculation warning into BUG

Now that we're confident our pax extended header calculation is correct,
turn the criticality of the assertion up to the maximum, from warning
right up to BUG.  Simplify the test, as the stderr comparison step would
not be reached in case the BUG message is triggered.

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

archive-tar: use size_t in strbuf_append_ext_header()

One of its callers already passes in a size_t value.  Use it
consistently in this function.

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

archive-tar: fix pax extended header length calculation

A pax extended header record starts with a decimal number.  Its value
is the length of the whole record, including its own length.

The calculation of that number in strbuf_append_ext_header() is off by
one in case the length of the rest is close to a higher order of
magnitude.  This affects paths and link targets a bit shorter than 1000,
10000, 100000 etc. characters -- paths with a length of up to 100 fit
into the tar header and don't need a pax extended header.

The mistake has been present since the function was added by ae64bbc18c
("tar-tree: Introduce write_entry()", 2006-03-25).

Account for digits added to len during the loop and keep incrementing
until we have enough space for len and the rest.  The crucial change is
to check against the current value of len before each iteration, instead
of against its value before the loop.

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

archive-tar: report wrong pax extended header length

Extended header entries contain a length value that is a bit tricky to
calculate because it includes its own length (number of decimal digits)
as well.  We get it wrong in corner cases.  Add a check, report wrong
results as a warning and add a test for exercising it.

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

merge-recursive: alphabetize include list

Other than cache.h which needs to appear first, and merge-recursive.h
which I want to be second so that we are more likely to notice if
merge-recursive.h has any missing includes, the rest of the list is
long and easier to look through if it's alphabetical.

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

merge-recursive: add sanity checks for relevant merge_options

There are lots of options that callers can set, yet most have a limited
range of valid values, some options are meant for output (e.g.
opt->obuf, which is expected to start empty), and callers are expected
to not set opt->priv.  Add several sanity checks to ensure callers
provide sane values.

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

merge-recursive: rename MERGE_RECURSIVE_* to MERGE_VARIANT_*

I want to implement the same outward facing API as found within
merge-recursive.h in a different merge strategy.  However, that makes
names like MERGE_RECURSIVE_{NORMAL,OURS,THEIRS} look a little funny;
rename to MERGE_VARIANT_{NORMAL,OURS,THEIRS}.

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

merge-recursive: split internal fields into a separate struct

merge_options has several internal fields that should not be set or read
by external callers.  This just complicates the API.  Move them into an
opaque merge_options_internal struct that is defined only in
merge-recursive.c and keep these out of merge-recursive.h.

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

merge-recursive: avoid losing output and leaking memory holding that output

If opt->buffer_output is less than 2, then merge_trees(),
merge_recursive(), and merge_recursive_generic() are all supposed to
flush the opt->obuf output buffer to stdout and release any memory it
holds.  merge_trees() did not do this.  Move the logic that handles this
for merge_recursive_internal() to merge_finalize() so that all three
methods handle this requirement.

Note that this bug didn't cause any problems currently, because there
are only two callers of merge_trees() right now (a git grep for
'merge_trees(' is misleading because builtin/merge-tree.c also defines a
'merge_tree' function that is unrelated), and only one of those is
called with buffer_output less than 2 (builtin/checkout.c), but it set
opt->verbosity to 0, for which there is only currently one non-error
message that would be shown: "Already up to date!".  However, that one
message can only occur when the merge is utterly trivial (the merge base
tree exactly matches the merge tree), and builtin/checkout.c already
attempts a trivial merge via unpack_trees() before falling back to
merge_trees().

Also, if opt->buffer_output is 2, then the caller is responsible to
handle showing any output in opt->obuf and for free'ing it.  This
requirement might be easy to overlook, so add a comment to
merge-recursive.h pointing it out.  (There are currently two callers
that set buffer_output to 2, both in sequencer.c, and both of which
handle this correctly.)

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

merge-recursive: comment and reorder the merge_options fields

The merge_options struct had lots of fields, making it a little
imposing, but the options naturally fall into multiple different groups.
Grouping similar options and adding a comment or two makes it easier to
read, easier for new folks to figure out which options are related, and
thus easier for them to find the options they need.

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

merge-recursive: consolidate unnecessary fields in merge_options

We provided users with the ability to state whether they wanted rename
detection, and to put a limit on how much CPU would be spent.  Both of
these fields had multiple configuration parameters for setting them,
with one being a fallback and the other being an override.  However,
instead of implementing the logic for how to combine the multiple
source locations into the appropriate setting at config loading time,
we loaded and tracked both values and then made the code combine them
every time it wanted to check the overall value.  This had a few
minor drawbacks:
  * it seems more complicated than necessary
  * it runs the risk of people using the independent settings in the
    future and breaking the intent of how the options are used
    together
  * it makes merge_options more complicated than necessary for other
    potential users of the API

Fix these problems by moving the logic for combining the pairs of
options into a single value; make it apply at time-of-config-loading
instead of each-time-of-use.

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

merge-recursive: move some definitions around to clean up the header

No substantive code changes (view this with diff --color-moved), but
a few small code cleanups:
  * Move structs and an inline function only used by merge-recursive.c
    into merge-recursive.c
  * Re-order function declarations to be more logical
  * Add or fix some explanatory comments

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

merge-recursive: rename merge_options argument to opt in header

In commit 259ccb6cc324 ("merge-recursive: rename merge_options argument
from 'o' to 'opt'", 2019-04-05), I renamed a bunch of function
arguments in merge-recursive.c, but forgot to make that same change to
merge-recursive.h.  Make the two match.

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

merge-recursive: rename 'mrtree' to 'result_tree', for clarity

It is not at all clear what 'mr' was supposed to stand for, at least not
to me.  Pick a clearer name for this variable.

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

merge-recursive: use common name for ancestors/common/base_list

merge_trees(), merge_recursive(), and merge_recursive_generic() in
their function headers used four different names for the merge base or
list of merge bases they were passed:
  * 'common'
  * 'ancestors'
  * 'ca'
  * 'base_list'
They were able to refer to it four different ways instead of only three
by using a different name in the signature for the .c file than the .h
file.  Change all of these to 'merge_base' or 'merge_bases'.

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

merge-recursive: fix some overly long lines

No substantive code change, just add some line breaks to fix lines that
have grown in length due to various refactorings.  Most remaining lines
of excessive length in merge-recursive include error messages and it's
not clear that splitting those improves things.

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

cache-tree: share code between functions writing an index as a tree

write_tree_from_memory() appeared to be a merge-recursive special that
basically duplicated write_index_as_tree().  The two have a different
signature, but the bigger difference was just that write_index_as_tree()
would always unconditionally read the index off of disk instead of
working on the current in-memory index.  So:

  * split out common code into write_index_as_tree_internal()

  * rename write_tree_from_memory() to write_inmemory_index_as_tree(),
    make it call write_index_as_tree_internal(), and move it to
    cache-tree.c

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

merge-recursive: don't force external callers to do our logging

Alternatively, you can view this as "make the merge functions behave
more similarly."  merge-recursive has three different entry points:
merge_trees(), merge_recursive(), and merge_recursive_generic().  Two of
these would call diff_warn_rename_limit(), but merge_trees() didn't.
This lead to callers of merge_trees() needing to manually call
diff_warn_rename_limit() themselves.  Move this to the new
merge_finalize() function to make sure that all three entry points run
this function.

Note that there are two external callers of merge_trees(), one in
sequencer.c and one in builtin/checkout.c.  The one in sequencer.c is
cleaned up by this patch and just transfers where the call to
diff_warn_rename_limit() is made; the one in builtin/checkout.c is for
switching to a different commit and in the very rare case where the
warning might be triggered, it would probably be helpful to include
(e.g. if someone is modifying a file that has been renamed in moving to
the other commit, but there are so many renames between the commits that
the limit kicks in and none are detected, it may help to have an
explanation about why they got a delete/modify conflict instead of a
proper content merge in a renamed file).

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

merge-recursive: remove useless parameter in merge_trees()

merge_trees() took a results parameter that would only be written when
opt->call_depth was positive, which is never the case now that
merge_trees_internal() has been split from merge_trees().  Remove the
misleading and unused parameter from merge_trees().

While at it, add some comments explaining how the output of
merge_trees() and merge_recursive() differ.

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

merge-recursive: exit early if index != head

We had a rule to enforce that the index matches head, but it was found
at the beginning of merge_trees() and would only trigger when
opt->call_depth was 0.  Since merge_recursive() doesn't call
merge_trees() until after returning from recursing, this meant that the
check wasn't triggered by merge_recursive() until it had first finished
all the intermediate merges to create virtual merge bases.  That is a
potentially huge amount of computation (and writing of intermediate
merge results into the .git/objects directory) before it errors out and
says, in effect, "Sorry, I can't do any merging because you have some
local changes that would be overwritten."

Further, not enforcing this requirement earlier allowed other bugs (such
as an unintentional unconditional dropping and reloading of the index in
merge_recursive() even when no recursion was necessary), to mask bugs in
other callers (which were fixed in the commit prior to this one).

Make sure we do the index == head check at the beginning of the merge,
and error out immediately if it fails.  While we're at it, fix a small
leak in the show-the-error codepath.

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

Ensure index matches head before invoking merge machinery, round N

This is the bug that just won't die; there always seems to be another
form of it somewhere.  See the commit message of 55f39cf7551b ("merge:
fix misleading pre-merge check documentation", 2018-06-30) for a more
detailed explanation), but in short:

<quick summary>

builtin/merge.c contains this important requirement for merge
strategies:

    ...the index must be in sync with the head commit.  The strategies are
    responsible to ensure this.

This condition is important to enforce because there are two likely
failure cases when the index isn't in sync with the head commit:

  * we silently throw away changes the user had staged before the merge

  * we accidentally (and silently) include changes in the merge that
    were not part of either of the branches/trees being merged

Discarding users' work and mis-merging are both bad outcomes, especially
when done silently, so naturally this rule was stated sternly -- but,
unfortunately totally ignored in practice unless and until actual bugs
were found.  But, fear not: the bugs from this were fixed in commit
  ee6566e8d70d ("[PATCH] Rewrite read-tree", 2005-09-05)
through a rewrite of read-tree (again, commit 55f39cf7551b has a more
detailed explanation of how this affected merge).  And it was fixed
again in commit
  160252f81626 ("git-merge-ours: make sure our index matches HEAD", 2005-11-03)
...and it was fixed again in commit
  3ec62ad9ffba ("merge-octopus: abort if index does not match HEAD", 2016-04-09)
...and again in commit
  65170c07d466 ("merge-recursive: avoid incorporating uncommitted changes in a merge", 2017-12-21)
...and again in commit
  eddd1a411d93 ("merge-recursive: enforce rule that index matches head before merging", 2018-06-30)

...with multiple testcases added to the testsuite that could be
enumerated in even more commits.

Then, finally, in a patch in the same series as the last fix above, the
documentation about this requirement was fixed in commit 55f39cf7551b
("merge: fix misleading pre-merge check documentation", 2018-06-30), and
we all lived happily ever after...

</quick summary>

Unfortunately, "ever after" apparently denotes a limited time and it
expired today.  The merge-recursive rule to enforce that index matches
head was at the beginning of merge_trees() and would only trigger when
opt->call_depth was 0.  Since merge_recursive() doesn't call
merge_trees() until after returning from recursing, this meant that the
check wasn't triggered by merge_recursive() until it had first finished
all the intermediate merges to create virtual merge bases.  That is a
potentially HUGE amount of computation (and writing of intermediate
merge results into the .git/objects directory) before it errors out and
says, in effect, "Sorry, I can't do any merging because you have some
local changes that would be overwritten."

Trying to enforce that all of merge_trees(), merge_recursive(), and
merge_recursive_generic() checked the index == head condition earlier
resulted in a bunch of broken tests.  It turns out that
merge_recursive() has code to drop and reload the cache while recursing
to create intermediate virtual merge bases, but unfortunately that code
runs even when no recursion is necessary.  This unconditional dropping
and reloading of the cache masked a few bugs:

  * builtin/merge-recursive.c: didn't even bother loading the index.

  * builtin/stash.c: feels like a fake 'builtin' because it repeatedly
    invokes git subprocesses all over the place, mixed with other
    operations.  In particular, invoking "git reset" will reset the
    index on disk, but the parent process that invoked it won't
    automatically have its in-memory index updated.

  * t3030-merge-recursive.h: this test has always been broken in that it
    didn't make sure to make index match head before running.  But, it
    didn't care about the index or even the merge result, just the
    verbose output while running.  While commit eddd1a411d93
    ("merge-recursive: enforce rule that index matches head before
    merging", 2018-06-30) should have uncovered this broken test, it
    used a test_must_fail wrapper around the merge-recursive call
    because it was known that the merge resulted in a rename/rename
    conflict.  Thus, that fix only made this test fail for a different
    reason, and since the index == head check didn't happen until after
    coming all the way back out of the recursion, the testcase had
    enough information to pass the one check that it did perform.

So, load the index in builtin/merge-recursive.c, reload the in-memory
index in builtin/stash.c, and modify the t3030 testcase to correctly
setup the index and make sure that the test fails in the expected way
(meaning it reports a rename/rename conflict).  This makes sure that
all callers actually make the index match head.  The next commit will
then enforce the condition that index matches head earlier so this
problem doesn't return in the future.

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

merge-recursive: remove another implicit dependency on the_repository

Commit d7cf3a96e9a0 ("merge-recursive.c: remove implicit dependency on
the_repository", 2019-01-12) and follow-ups like commit 34e7771bc644
("Use the right 'struct repository' instead of the_repository",
2019-06-27), removed most implicit uses of the_repository.  Convert
calls to get_commit_tree() to instead use repo_get_commit_tree() to get
rid of another.

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

merge-recursive: future-proof update_file_flags() against memory leaks

There is a 'free_buf' label to which all but one of the error paths in
update_file_flags() jump; that error case involves a NULL buf and is
thus not a memory leak.  However, make that error case execute the same
deallocation code anyway so that if anyone adds any additional memory
allocations or deallocations, then all error paths correctly deallocate
resources.

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

merge-recursive: introduce an enum for detect_directory_renames values

Improve code readability by introducing an enum to replace the
not-quite-boolean values taken on by detect_directory_renames.

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

merge-recursive: provide a better label for diff3 common ancestor

In commit 7ca56aa07619 ("merge-recursive: add a label for ancestor",
2010-03-20), a label was added for the '||||||' line to make it have
the more informative heading '|||||| merged common ancestors', with
the statement:

    It would be nicer to use a more informative label.  Perhaps someone
    will provide one some day.

This chosen label was perfectly reasonable when recursiveness kicks in,
i.e. when there are multiple merge bases.  (I can't think of a better
label in such cases.)  But it is actually somewhat misleading when there
is a unique merge base or no merge base.  Change this based on the
number of merge bases:
    >=2: "merged common ancestors"
    1:   <abbreviated commit hash>
    0:   "<empty tree>"

Tests have also been added to check that we get the right ancestor name
for each of the three cases.

Also, since merge_recursive() and merge_trees() have polar opposite
pre-conditions for opt->ancestor, document merge_recursive()'s
pre-condition with an assertion.  (An assertion was added to
merge_trees() already a few commits ago.)  The differences in
pre-conditions stem from two factors: (1) merge_trees() does not recurse
and thus does not have multiple sub-merges to worry about -- each of
which would require a different value for opt->ancestor, (2)
merge_trees() is only passed trees rather than commits and thus cannot
internally guess as good of a label.  Thus, while external callers of
merge_trees() are required to provide a non-NULL opt->ancestor,
merge_recursive() expects to set this value itself.

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

l10n: sv.po: Update Swedish translation (4674t0f0u)

Signed-off-by: Peter Krefting <redacted>

l10n: Update Catalan translation

Signed-off-by: Jordi Mas <redacted>

merge-recursive: enforce opt->ancestor != NULL when calling merge_trees()

We always want our conflict hunks to be labelled so that users can know
where each came from.  The previous commit fixed the one caller in the
codebase which was not setting opt->ancestor (and thus not providing a
label for the "merge base" conflict hunk in diff3-style conflict
markers); add an assertion to prevent future codepaths from also
overlooking this requirement.

Enforcing this requirement also allows us to simplify the code for
labelling the conflict hunks by no longer checking if the ancestor label
is NULL.

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

checkout: provide better conflict hunk description with detached HEAD

When running 'git checkout -m' and using diff3 style conflict markers,
we want all the conflict hunks (left-side, "common" or "merge base", and
right-side) to have label markers letting the user know where each came
from.  The "common" hunk label (o.ancestor) came from
old_branch_info->name, but that is NULL when HEAD is detached, which
resulted in a blank label.  Check for that case and provide an
abbreviated commit hash instead.

(Incidentally, this was the only case in the git codebase where
merge_trees() was called with opt->ancestor being NULL.  A subsequent
commit will prevent similar problems by enforcing that merge_trees()
always be called with opt->ancestor != NULL.)

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

merge-recursive: be consistent with assert

In commit 8daec1df03de ("merge-recursive: switch from (oid,mode) pairs
to a diff_filespec", 2019-04-05), an assertion on a->path && b->path
was added for code readability to document that these both needed to be
non-NULL at this point in the code.  However, the subsequent lines also
read o->path, so it should be included in the assert.

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

Git 2.23

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

Merge tag 'l10n-2.23.0-rnd2' of git://github.com/git-l10n/git-po

l10n-2.23.0-rnd2

checkout: remove duplicate code

Both commit a7256debd4b6 ("checkout.txt: note about losing staged
changes with --merge", 2019-03-19) from nd/checkout-m-doc-update and
commit 6eff409e8a76 ("checkout: prevent losing staged changes with
--merge", 2019-03-22) from nd/checkout-m were included in git.git
despite the fact that the latter was meant to be v2 of the former.
The merge of these two topics resulted in a redundant chunk of code;
remove it.

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

l10n: zh_CN: for git v2.23.0 l10n round 1~2

Translate 128 new messages (4674t0f0u) for git 2.23.0.

Signed-off-by: Jiang Xin <redacted>

http: use xmalloc with cURL

f0ed8226c9 (Add custom memory allocator to MinGW and MacOS builds, 2009-05-31)
never told cURL about it.

Correct that by using the cURL initializer available since version 7.12 to
point to xmalloc and friends for consistency which then will pass the
allocation requests along when USE_NED_ALLOCATOR=YesPlease is used (most
likely in Windows)

Signed-off-by: Carlo Marcelo Arenas Belón <redacted>
Signed-off-by: Junio C Hamano <redacted>

diff: 'diff.indentHeuristic' is no longer experimental

The indent heuristic started out as experimental, but it's now our
default diff heuristic since 33de716387 (diff: enable indent heuristic
by default, 2017-05-08).  Alas, that commit didn't update the
documentation, and the description of the 'diff.indentHeuristic'
configuration variable still implies that it's experimental and not
the default.

Update the description of 'diff.indentHeuristic' to make it clear that
it's the default diff heuristic.

The description of the related '--indent-heuristic' option has already
been updated in bab76141da (diff: --indent-heuristic is no
longer experimental, 2017-10-29).

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

repo-settings: create feature.experimental setting

The 'feature.experimental' setting includes config options that are
not committed to become defaults, but could use additional testing.

Update the following config settings to take new defaults, and to
use the repo_settings struct if not already using them:

* 'pack.useSparse=true'

* 'fetch.negotiationAlgorithm=skipping'

In the case of fetch.negotiationAlgorithm, the existing logic
would load the config option only when about to use the setting,
so had a die() statement on an unknown string value. This is
removed as now the config is parsed under prepare_repo_settings().
In general, this die() is probably misplaced and not valuable.
A test was removed that checked this die() statement executed.

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

repo-settings: create feature.manyFiles setting

The feature.manyFiles setting is suitable for repos with many
files in the working directory. By setting index.version=4 and
core.untrackedCache=true, commands such as 'git status' should
improve.

While adding this setting, modify the index version precedence
tests to check how this setting overrides the default for
index.version is unset.

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

repo-settings: parse core.untrackedCache

The core.untrackedCache config setting is slightly complicated,
so clarify its use and centralize its parsing into the repo
settings.

The default value is "keep" (returned as -1), which persists the
untracked cache if it exists.

If the value is set as "false" (returned as 0), then remove the
untracked cache if it exists.

If the value is set as "true" (returned as 1), then write the
untracked cache and persist it.

Instead of relying on magic values of -1, 0, and 1, split these
options into an enum. This allows the use of "-1" as a
default value. After parsing the config options, if the value is
unset we can initialize it to UNTRACKED_CACHE_KEEP.

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

commit-graph: turn on commit-graph by default

The commit-graph feature has seen a lot of activity in the past
year or so since it was introduced. The feature is a critical
performance enhancement for medium- to large-sized repos, and
does not significantly hurt small repos.

Change the defaults for core.commitGraph and gc.writeCommitGraph
to true so users benefit from this feature by default.

There are several places in the test suite where the environment
variable GIT_TEST_COMMIT_GRAPH is disabled to avoid reading a
commit-graph, if it exists. The config option overrides the
environment, so swap these. Some GIT_TEST_COMMIT_GRAPH assignments
remain, and those are to avoid writing a commit-graph when a new
commit is created.

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

t6501: use 'git gc' in quiet mode

t6501-freshen-objects.sh sends the standard error from
'git gc' to a file and verifies that it is empty. This
is intended as a way to ensure no warnings are written
during the operation. However, as the commit-graph is
added as a step to 'git gc', its progress will appear
in the output.

Pass the '-q' argument to avoid a failing test case
when progress is written.

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

repo-settings: consolidate some config settings

There are a few important config settings that are not loaded
during git_default_config. These are instead loaded on-demand.

Centralize these config options to a single scan, and store
all of the values in a repo_settings struct. The values for
each setting are initialized as negative to indicate "unset".

This centralization will be particularly important in a later
change to introduce "meta" config settings that change the
defaults for these config settings.

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

worktree remove: clarify error message on dirty worktree

To avoid data loss, 'git worktree remove' refuses to delete a worktree
if it's dirty or contains untracked files.  However, the error message
only mentions that the worktree "is dirty", even if the worktree in
question is in fact clean, but contains untracked files:

  $ git worktree add test-worktree
  Preparing worktree (new branch 'test-worktree')
  HEAD is now at aa53e60 Initial
  $ >test-worktree/untracked-file
  $ git worktree remove test-worktree/
  fatal: 'test-worktree/' is dirty, use --force to delete it
  $ git -C test-worktree/ diff
  $ git -C test-worktree/ diff --cached
  $ # Huh?  Where are those dirty files?!

Clarify this error message to say that the worktree "contains modified
or untracked files".

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

completion: complete config variables and values for 'git clone --config='

Completing configuration sections and variable names for the stuck
argument of 'git clone --config=<TAB>' requires a bit of extra care
compared to doing the same for the unstuck argument of 'git clone
--config <TAB>', because we have to deal with that '--config=' being
part of the current word to be completed.

Add an option to the __git_complete_config_variable_name_and_value()
and in turn to the __git_complete_config_variable_name() helper
functions to specify the current section/variable name to be
completed, so they can be used even when completing the stuck argument
of '--config='.

__git_complete_config_variable_value() already has such an option, and
thus no further changes were necessary to complete possible values
after 'git clone --config=section.name=<TAB>'.

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

completion: complete config variables names and values for 'git clone -c'

The previous commits taught the completion script how to complete
configuration section, variable names, and their valus after 'git -c
<TAB>', and with a bit of foresight encapsulated all that in a
dedicated helper function.  Use that function to complete the unstuck
argument of 'git config -c|--config <TAB>', which expect configuration
variables and values in the same 'section.name=value' form.

Note that handling the struck argument for 'git clone --config=<TAB>'
requires some extra care, so it will be done a separate patch.

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

completion: complete values of configuration variables after 'git -c var='

'git config' expects a configuration variable's name and value in
separate options, so we complete values as they stand on their own on
the command line.  'git -c', however, expects them in a single option
joined by a '=' character, so we should be able to complete values
when they are following 'section.name=' in the same word.

Add new options to the __git_complete_config_variable_value() function
to allow callers to specify the current word to be completed and the
configuration variable whose value is to be completed, and use these
to complete possible values after 'git -c 'section.name=<TAB>'.

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

completion: complete configuration sections and variable names for 'git -c'

'git config' expects a configuration variable's name and value in
separate arguments, so we let the __gitcomp() helper append a space
character to each variable name by default, like we do for most other
things (--options, refs, paths, etc.).  'git -c', however, expects
them in a single option joined by a '=' character, i.e.
'section.name=value', so we should append a '=' character to each
fully completed variable name, but no space, so the user can continue
typing the value right away.

Add an option to the __git_complete_config_variable_name() function to
allow callers to specify an alternate suffix to add, and use it to
append that '=' character to configuration variables.  Update the
__gitcomp() helper function to not append a trailing space to any
completion words ending with a '=', not just to those option with a
stuck argument.

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

completion: split _git_config()

_git_config() contains two enormous case statements, one to complete
configuration sections and variable names, and the other to complete
their values.

Split these out into two separate helper functions, so in the next
patches we can use them to implement completion for 'git -c <TAB>'.

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

completion: simplify inner 'case' pattern in __gitcomp()

The second '*' in the '--*=*' pattern of the inner 'case' statement of
the __gitcomp() helper function never matches anything, so let's use
'--*=' instead.

The purpose of that inner case statement is to decide when to append a
trailing space to the listed options and when not.  When an option
requires a stuck argument, i.e. '--option=', then the trailing space
should not be added, so the user can continue typing the required
argument right away.  That '--*=*' pattern is supposed to match these
options, but for this purpose that second '*' is unnecessary, a '--*='
pattern works just as well.  That second '*' would only make a
difference in case of a possible completion word like
'--option=value', but our completion script never passes such a word
to __gitcomp(), because the '--option=' and its 'value' must be
completed separately.

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

completion: use 'sort -u' to deduplicate config variable names

The completion script runs the classic '| sort | uniq' pipeline to
deduplicate the output of 'git help --config-for-completion'.  'sort
-u' does the same, but uses one less external process and pipeline
stage.  Not a bit win, as it's only run once as the list of supported
configuration variables is initialized, but at least it sets a better
example for others to follow.

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

completion: deduplicate configuration sections

The number of configuration variables listed by the completion script
grew quite when we started to auto-generate it from the documentation
[1], so we now complete them in two steps: first we list only the
section names, then the rest [2].  To get the section names we simply
strip everything following the first dot in each variable name,
resulting in a lot of repeated section names, because most sections
contain more than one configuration variable.  This is not a
correctness issue in practice, because Bash's completion facilities
remove all repetitions anyway, but these repetitions make testing a
bit harder.

Replace the small 'sed' script removing subsections and variable names
with an 'awk' script that does the same, and in addition removes any
repeated configuration sections as well (by first creating and filling
an associative array indexed by all encountered configuration
sections, and then iterating over this array and printing the indices,
i.e. the unique section names).  This change makes the failing 'git
config - section' test in 't9902-completion.sh' pass.

Note that this changes the order of section names in the output, and
makes it downright undeterministic, but this is not an issue, because
Bash sorts them before presenting them to the user, and our completion
tests sort them as well before comparing with the expected output.

Yeah, it would be simpler and shorter to just append '| sort -u' to
that command, but that would incur the overhead of one more external
process and pipeline stage every time a user completes configuration
sections.

[1] e17ca92637 (completion: drop the hard coded list of config vars,
    2018-05-26)
[2] f22f682695 (completion: complete general config vars in two steps,
    2018-05-27)

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

completion: add tests for 'git config' completion

The next patches will change/refactor the way we complete
configuration variable names and values, so add a few tests to cover
the basics, namely the completion of matching configuration sections,
full variable names, and their values.

Note that the test checking the completion of configuration sections
is currently failing, though it's not a sign of an actual bug.  If a
section contains multiple variables, then that section is currently
repeated as many times as the number of variables in there.  This is
not a correctness issue in practice, because Bash's completion
facilities remove all repetitions anyway.  Consequently, we could list
all those repeated sections in the expected output of this test as
well, but then it would have to be updated whenever a new
configuration variable is added to those sections.  Instead, list each
matching configuration section only once, mark the test as failing for
now, and the next patch will update the completion script to avoid
those repetitions.

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

completion: complete more values of more 'color.*' configuration variables

Most 'color.*' configuration variables, with the sole exception of
'color.pager', accept the same set of values, but our completion
script recognizes only about half of them.  We could explicitly add
all those missing variables, but let's try to reduce future
maintenance burden, and use the catch-all 'color.*' pattern instead,
so this list won't get out of sync when a similar new configuration
variable accepting the same values is introduced [1].

Furthermore, their documentation explicitly mentions that they all
accept the standard boolean values 'false' and 'true' as well, so list
these, too, among the possible values.

[1] OTOH, there will be a maintenance burden if ever a new
    'color.something' is introduced which doesn't accept the same set
    of values.  We'll see which one happens first...

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

completion: fix a typo in a comment

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

packfile: drop release_pack_memory()

Long ago, in 97bfeb34df (Release pack windows before reporting out of
memory., 2006-12-24), we taught xmalloc() and friends to try unmapping
pack windows when malloc() failed. It's unlikely that his helps a lot in
practice, and it has some downsides. First, the downsides:

  1. It makes xmalloc() not thread-safe. We've worked around this in
     pack-objects.c, which installs its own locking version of the
     try_to_free_routine(). But other threaded code doesn't.

  2. It makes the system as a whole harder to reason about. Functions
     which allocate heap memory under the hood may have farther-reaching
     effects than expected.

That might be worth the tradeoff if there's a benefit. But in practice,
it seems unlikely. We're generally dealing with mmap'd files, so the OS
is going to do a much better job at responding to memory pressure by
dropping individual pages (the exception is systems with NO_MMAP, but
even there the OS can probably respond just as well with swapping).

So the only thing we're really freeing is address space. On 64-bit
systems, we have plenty of that to go around. On 32-bit systems, it
could possibly help. But around the same time we made two other changes:
77ccc5bbd1 (Introduce new config option for mmap limit., 2006-12-23) and
60bb8b1453 (Fully activate the sliding window pack access., 2006-12-23).
Together that means that a 32-bit system should have no more than 256MB
total of packed-git mmaps at one time, split between a few 32MB windows.
It's unlikely we have any address space problems since then, but we
don't have any data since the features were all added at the same time.

Likewise, xmmap() will try to free memory. At first glance, it seems
like we'd need this (when we try to mmap a new window, we might need to
close an old one to save address space on a 32-bit system). But we're
saved again by core.packedGitLimit: if we're going to exceed our 256MB
limit, we'll close an existing window before we even call mmap().

So it seems unlikely that this feature is actually doing anything
useful. And while we don't have reports of it harming anything (probably
because it rarely if ever kicks in), it would be nice to simplify the
system overall. This patch drops the whole try_to_free system from
xmalloc(), as well as the manual pack memory release in xmmap().

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

git-fast-import.txt: clarify that multiple merge commits are allowed

The grammar for commits used a '?' rather than a '*' on the `merge`
directive line, despite the fact that the code allows multiple `merge`
directives in order to support n-way merges.  In fact, elsewhere in
git-fast-import.txt there is an explicit declaration that "an unlimited
number of `merge` commands per commit are permitted by fast-import".
Fix the grammar to match the intent and implementation.

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

l10n: de.po: Update German translation

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

t/perf: rename duplicate-numbered test script

There are two perf scripts numbered p5600, but with otherwise different
names ("clone-reference" versus "partial-clone"). We store timing
results in files named after the whole script, so internally we don't
get confused between the two. But "aggregate.perl" just prints the test
number for each result, giving multiple entries for "5600.3". It also
makes it impossible to skip one test but not the other with
GIT_SKIP_TESTS.

Let's renumber the one that appeared later (by date -- the source of the
problem is that the two were developed on independent branches). For the
non-perf test suite, our test-lint rule would have complained about this
when the two were merged, but t/perf never learned that trick.

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

Merge branch 'master' of https://github.com/vnwildman/git

* 'master' of https://github.com/vnwildman/git:
  l10n: vi(4674t): Updated translation for Vietnamese

Merge branch 'update-italian-translation' of github.com:AlessandroMenti/git-po

* 'update-italian-translation' of github.com:AlessandroMenti/git-po:
  l10n: it.po: update the Italian localization for v2.23.0 round 2

Merge branch 'next' of https://github.com/ChrisADR/git-po

* 'next' of https://github.com/ChrisADR/git-po:
  l10n: es: 2.23.0 round 2

Sync with Git 2.22.1

doc: fix repeated words

Inspired by 21416f0a07 ("restore: fix typo in docs", 2019-08-03), I ran
"git grep -E '(\b[a-zA-Z]+) \1\b' -- Documentation/" to find other cases
where words were duplicated, e.g. "the the", and in most cases removed
one of the repeated words.

There were many false positives by this grep command, including
deliberate repeated words like "really really" or valid uses of "that
that" which I left alone, of course.

I also did not correct any of the legitimate, accidentally repeated
words in old RelNotes.

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

Git 2.22.1

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

.mailmap: update email address of Philip Oakley

My IEE 'home for life' email service is being withdrawn on 30 Sept 2019.
Replace with my new email domain.

I also have a secondary (backup) 'home for life' through
<redacted>.

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

l10n: it.po: update the Italian localization for v2.23.0 round 2

Signed-off-by: Alessandro Menti <redacted>

l10n: vi(4674t): Updated translation for Vietnamese

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

l10n: es: 2.23.0 round 2

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

l10n: fr v2.23.0 round 2

Signed-off-by: Jean-Noël Avila <redacted>

l10n: git.pot: v2.23.0 round 2 (4 new, 6 removed)

Generate po/git.pot from v2.23.0-rc2 for git v2.23.0 l10n round 2.

Signed-off-by: Jiang Xin <redacted>

Merge tag 'v2.23.0-rc2' of git://git./git/git

Git 2.23-rc2

* tag 'v2.23.0-rc2' of git://git.kernel.org/pub/scm/git/git: (63 commits)
  Git 2.23-rc2
  t0000: reword comments for "local" test
  t: decrease nesting in test_oid_to_path
  sha1-file: release strbuf after use
  test-dir-iterator: use path argument directly
  dir-iterator: release strbuf after use
  commit-graph: release strbufs after use
  l10n: reformat some localized strings for v2.23.0
  merge-recursive: avoid directory rename detection in recursive case
  commit-graph: fix bug around octopus merges
  restore: fix typo in docs
  doc: typo: s/can not/cannot/ and s/is does/does/
  Git 2.23-rc1
  log: really flip the --mailmap default
  RelNotes/2.23.0: fix a few typos and other minor issues
  RelNotes/2.21.1: typofix
  log: flip the --mailmap default unconditionally
  config: work around bug with includeif:onbranch and early config
  A few more last-minute fixes
  repack: simplify handling of auto-bitmaps and .keep files
  ...

l10n: bg.po: Updated Bulgarian translation (4674t)

Signed-off-by: Alexander Shopov <redacted>

Merge branch 'cb/xdiff-no-system-includes-in-dot-c' into maint

Compilation fix.

* cb/xdiff-no-system-includes-in-dot-c:
  xdiff: remove duplicate headers from xpatience.c
  xdiff: remove duplicate headers from xhistogram.c
  xdiff: drop system includes in xutils.c

Merge branch 'jk/no-system-includes-in-dot-c' into maint

Compilation fix.

* jk/no-system-includes-in-dot-c:
  wt-status.h: drop stdio.h include
  verify-tag: drop signal.h include

Merge branch 'sg/fsck-config-in-doc' into maint

Doc update.

* sg/fsck-config-in-doc:
  Documentation/git-fsck.txt: include fsck.* config variables

Merge branch 'jk/xdiff-clamp-funcname-context-index' into maint

The internal diff machinery can be made to read out of bounds while
looking for --funcion-context line in a corner case, which has been
corrected.

* jk/xdiff-clamp-funcname-context-index:
  xdiff: clamp function context indices in post-image

trace2: cleanup whitespace in perf format

Make use of new sq_append_quote_argv_pretty() to normalize
how we handle leading whitespace in perf format messages.

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

trace2: cleanup whitespace in normal format

Make use of new sq_append_quote_argv_pretty() to normalize
how we handle leading whitespace in normal format messages.

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

quote: add sq_append_quote_argv_pretty()

sq_quote_argv_pretty() builds a "pretty" string from the given argv.
It inserts whitespace before each value, rather than just between
them, so the resulting string always has a leading space.  Lets give
callers an option to not have the leading space or have to ltrim()
it later.

Create sq_append_quote_argv_pretty() to convert an argv into a
pretty, quoted if necessary, string with space delimiters and
without a leading space.

Convert the existing sq_quote_argv_pretty() to use this new routine
while preserving the leading space behavior.

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

Git 2.23-rc2

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

Merge branch 'bc/hash-independent-tests-part-4'

Test fix.

* bc/hash-independent-tests-part-4:
  t0000: reword comments for "local" test
  t: decrease nesting in test_oid_to_path

Merge branch 'rs/plug-strbuf-reak-in-read-alt-refs'

Leakfix.

* rs/plug-strbuf-reak-in-read-alt-refs:
  sha1-file: release strbuf after use

Merge branch 'mt/dir-iterator-updates'

Leakfix.

* mt/dir-iterator-updates:
  test-dir-iterator: use path argument directly
  dir-iterator: release strbuf after use

Merge branch 'ds/commit-graph-incremental'

Leakfix.

* ds/commit-graph-incremental:
  commit-graph: release strbufs after use

Merge branch 'ja/l10n-fixes'

A few messages have been updated to help localization better.

* ja/l10n-fixes:
  l10n: reformat some localized strings for v2.23.0

Merge branch 'en/disable-dir-rename-in-recursive-merge'

"merge-recursive" hit a BUG() when building a virtual merge base
detected a directory rename.

* en/disable-dir-rename-in-recursive-merge:
  merge-recursive: avoid directory rename detection in recursive case

Merge branch 'nd/switch-and-restore'

Docfix.

* nd/switch-and-restore:
  restore: fix typo in docs

Merge branch 'mr/doc-can-not-to-cannot'

Docfix.

* mr/doc-can-not-to-cannot:
  doc: typo: s/can not/cannot/ and s/is does/does/

Merge branch 'ds/commit-graph-octopus-fix'

commit-graph did not handle commits with more than two parents
correctly, which has been corrected.

* ds/commit-graph-octopus-fix:
  commit-graph: fix bug around octopus merges

trace2: trim trailing whitespace in normal format error message

Avoid creating unnecessary trailing whitespace in normal
target format error messages when the message is omitted.

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

trace2: remove dead code in maybe_add_string_va()

Remove an unnecessary "if" block in maybe_add_string_va().

Commit "ad006fe419e trace2: NULL is not allowed for va_list"
changed "if (fmt && *fmt && ap)" to just "if (fmt && *fmt)"
because it isn't safe to treat 'ap' as a pointer.  This made
the "if" block following it unnecessary.

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

trace2: trim whitespace in region messages in perf target format

Avoid unecessary trailing whitespace in "region_enter" and "region_leave"
messages in perf target format.

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

t0000: reword comments for "local" test

Commit 01d3a526ad (t0000: check whether the shell supports the "local"
keyword, 2017-10-26) added a test to gather data on whether people run
the test suite with shells that don't support "local".

After almost two years, nobody has complained, and several other uses
have cropped up in test-lib-functions.sh. Let's declare it acceptable to
use.

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

t: decrease nesting in test_oid_to_path

t1410.3 ("corrupt and checks") fails when run using dash versions
before 0.5.8, with a cryptic message:

mv: cannot stat '.git/objects//e84adb2704cbd49549e52169b4043871e13432': No such file or directory

The function generating that path:

test_oid_to_path () {
echo "${1%${1#??}}/${1#??}"
}

which is supposed to produce a result like

12/3456789....

But a dash bug[*] causes it to instead expand to

/3456789...

The stream of symbols that makes up this function is hard for humans
to follow, too.  The complexity mostly comes from the repeated use of
the expression ${1#??} for the basename of the loose object.  Use a
variable instead --- nowadays, the dialect of shell used by Git
permits local variables, so this is cheap.

An alternative way to work around [*] is to remove the double-quotes
around test_oid_to_path's return value.  That makes the expression
easier for dash to read, but harder for humans.  Let's prefer the
rephrasing that's helpful for humans, too.

Noticed by building on Ubuntu trusty, which uses dash 0.5.7.

[*] Fixed by v0.5.8~13 ("[EXPAND] Propagate EXP_QPAT in subevalvar, 2013-08-23).

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

Merge branch 'py/call-do-quit-before-exit' of github.com:gitster/git-gui into py/git-gui-do-quit

* 'py/call-do-quit-before-exit' of github.com:gitster/git-gui:
  git-gui: call do_quit before destroying the main window

git-gui: call do_quit before destroying the main window

If the toplevel window for the window being destroyed is the main window
(aka "."), then simply destroying it means the cleanup tasks are not
executed (like saving the commit message buffer, saving window state,
etc.)

All this is handled by do_quit.  Call it instead of directly
destroying the main window. For other toplevel windows, the old
behavior remains.

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

merge: --no-verify to bypass pre-merge-commit hook

Analogous to commit, introduce a '--no-verify' option which bypasses the
pre-merge-commit hook. The shorthand '-n' is taken by '--no-stat'
already.

[js: * reworded commit message to reflect current state of --no-stat flag
       and new hook name
     * fixed flag documentation to reflect new hook name
     * cleaned up trailing whitespace
     * squashed test changes from the original series' patch 4/4
     * modified tests to follow pattern from this series' patch 1/4
     * added a test case for --no-verify with non-executable hook
     * when testing that the merge hook did not run, make sure we
       actually have a merge to perform (by resetting the "side" branch
       to its original state).

]

Improved-by: Martin Ågren <redacted>
Signed-off-by: Michael J Gruber <redacted>
Signed-off-by: Martin Ågren <redacted>
Signed-off-by: Josh Steadmon <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-merge: honor pre-merge-commit hook

git-merge does not honor the pre-commit hook when doing automatic merge
commits, and for compatibility reasons this is going to stay.

Introduce a pre-merge-commit hook which is called for an automatic merge
commit just like pre-commit is called for a non-automatic merge commit
(or any other commit).

[js: * renamed hook from "pre-merge" to "pre-merge-commit"
     * only discard the index if the hook is actually present
     * expanded githooks documentation entry
     * clarified that hook should write messages to stderr
     * squashed test changes from the original series' patch 4/4
     * modified tests to follow new pattern from this series' patch 1/4
     * added a test case for non-executable merge hooks
     * added a test case for failed merges
     * when testing that the merge hook did not run, make sure we
       actually have a merge to perform (by resetting the "side" branch
       to its original state).
     * reworded commit message
]

Improved-by: Martin Ågren <redacted>
Signed-off-by: Michael J Gruber <redacted>
Signed-off-by: Martin Ågren <redacted>
Signed-off-by: Josh Steadmon <redacted>
Signed-off-by: Junio C Hamano <redacted>

merge: do no-verify like commit

f8b863598c ("builtin/merge: honor commit-msg hook for merges", 2017-09-07)
introduced the no-verify flag to merge for bypassing the commit-msg
hook, though in a different way from the implementation in commit.c.

Change the implementation in merge.c to be the same as in commit.c so
that both do the same in the same way. This also changes the output of
"git merge --help" to be more clear that the hook return code is
respected by default.

[js: * reworded commit message
     * squashed documentation changes from original series' patch 3/4
]

Signed-off-by: Michael J Gruber <redacted>
Signed-off-by: Josh Steadmon <redacted>
Signed-off-by: Junio C Hamano <redacted>

t7503: verify proper hook execution

t7503 did not verify that the expected hooks actually ran during
testing. Fix that by making the hook scripts write their $0 into a file
so that we can compare actual execution vs. expected execution.

While we're at it, do some test style cleanups, such as using
write_script() and doing setup inside a test_expect_success block.

Improved-by: Martin Ågren <redacted>
Signed-off-by: Martin Ågren <redacted>
Signed-off-by: Josh Steadmon <redacted>
Signed-off-by: Junio C Hamano <redacted>