Merge branch 'st/dark-mode' into master

Improve dark mode support. Do not hard-code widget colors and instead
pull them from the current theme and update them in the options
database.

* st/dark-mode:
  git-gui: improve dark mode support

Merge branch 'fr_2.29.0_rnd_1' of github.com:jnavila/git

* 'fr_2.29.0_rnd_1' of github.com:jnavila/git:
  l10n: fr: v2.29.0 rnd 1

help: do not expect built-in commands to be hardlinked

When building with SKIP_DASHED_BUILT_INS=YesPlease, the built-in
commands are no longer present in the `PATH` as hardlinks to `git`.

As a consequence, `load_command_list()` needs to be taught to find the
names of the built-in commands from elsewhere.

This only affected the output of `git --list-cmds=main`, but not the
output of `git help -a` because the latter includes the built-in
commands by virtue of them being listed in command-list.txt.

The bug was detected via a patch series that turns the merge strategies
included in Git into built-in commands: `git merge -s help` relies on
`load_command_list()` to determine the list of available merge
strategies.

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

index-pack: make get_base_data() comment clearer

A comment mentions that we may free cached delta bases via
find_unresolved_deltas(), but that function went away in f08cbf60fe
(index-pack: make quantum of work smaller, 2020-09-08). Since we need to
rewrite that comment anyway, make the entire comment clearer.

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

l10n: fr: v2.29.0 rnd 1

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

l10n: it.po: update the Italian translation for Git 2.29.0 round 1

Signed-off-by: Alessandro Menti <redacted>

index-pack: drop type_cas mutex

The type_cas lock lost all of its callers in f08cbf60fe (index-pack:
make quantum of work smaller, 2020-09-08), so we can safely delete it.
The compiler didn't alert us that the variable became unused, because we
still call pthread_mutex_init() and pthread_mutex_destroy() on it.

It's worth considering also whether that commit was in error to remove
the use of the lock. Why don't we need it now, if we did before, as
described in ab791dd138 (index-pack: fix race condition with duplicate
bases, 2014-08-29)? I think the answer is that we now look at and assign
the child_obj->real_type field in the main thread while holding the
work_lock(). So we don't have to worry about racing with the worker
threads.

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

index-pack: restore "resolving deltas" progress meter

Commit f08cbf60fe (index-pack: make quantum of work smaller, 2020-09-08)
refactored the main loop in threaded_second_pass(), but also deleted the
call to display_progress() at the top of the loop. This means that users
typically see no progress at all during the delta resolution phase (and
for large repositories, Git appears to hang).

This looks like an accident that was unrelated to the intended change of
that commit, since we continue to update nr_resolved_deltas in
resolve_delta(). Let's restore the call to get that progress back.

We'll also add a test that confirms we generate the expected progress.
This isn't perfect, as it wouldn't catch a bug where progress was
delayed to the end. That was probably possible to trigger when receiving
a thin pack, because we'd eventually call display_progress() from
fix_unresolved_deltas(), but only once after doing all the work.
However, since our test case generates a complete pack, it reliably
demonstrates this particular bug and its fix. And we can't do better
without making the test racy.

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

git-completion.bash: stash-show: complete $__git_diff_common_options

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

git-completion.bash: __git_diff_common_options: add --[no-]patch

At the same time also deduplicate those options from command completions
which use $__git_diff_common_options.

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

compat/mingw.h: drop extern from function declaration

In 554544276a (*.[ch]: remove extern from function declarations using
spatch, 2019-04-29), `extern` on function declarations were declared to
be redundant and thus removed from the codebase. An `extern` was
accidentally reintroduced in 08809c09aa (mingw: add a helper function to
attach GDB to the current process, 2020-02-13).

Remove this spurious `extern`.

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

GitHub workflow: automatically follow minor updates of setup-msbuild

It is the custom to follow minor updates of GitHub Actions
automatically, by using the suffix `@v1`. Actions' maintainers will then
update that `v1` ref to point to the newest.

However, for `microsoft/setup-msbuild`, 889cacb6897 (ci: configure
GitHub Actions for CI/PR, 2020-04-11) uses a very specific `@v1.0.0`
suffix.

In this instance, that is a problem: should `setup-msbuild` release a
new version that intends to fix a critical bug, we won't know it, and we
won't use it.

Such a scenario is not theoretical. It is happening right now:
https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands

Let's simplify our setup, allowing us to benefit from automatically
using the newest v1.x.

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

t2016: add a NEEDSWORK about the PERL prerequisite

Since the builtin add-p is used when $GIT_TEST_ADD_I_USE_BUILTIN is
given, we should replace the PERL prerequisite with an ADD_I
prerequisite which first checks if $GIT_TEST_ADD_I_USE_BUILTIN is
defined before checking PERL.[0] Mark this in a NEEDSWORK so that it can
be addressed at a later time.

[0]: https://lore.kernel.org/git/xmqqsgat7ttf.fsf@gitster.c.googlers.com/

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

add-patch: add NEEDSWORK about comparing commits

The two versions of add-patch has special-casing for the literal
revision "HEAD". However, we want to handle other ways of saying "HEAD"
in the same way.[0] Add a NEEDSWORK to the add-patch code that does this
so that it can be addressed later.

[0]: https://lore.kernel.org/git/xmqqsgat7ttf.fsf@gitster.c.googlers.com/

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

Doc: document "A...B" form for <tree-ish> in checkout and switch

Using "A...B" has been supported for the <tree-ish> argument for a
while. However, its support has never been explicitly documented.

Explicitly document it so that users know that it is available.

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

builtin/checkout: fix `git checkout -p HEAD...` bug

Running `git checkout -p` with a merge-base rev results in an error:

$ git checkout -p HEAD...
usage: git diff-index [-m] [--cached] [<common-diff-options>] <tree-ish> [<path>...]
common diff options:
  -z            output diff-raw with lines terminated with NUL.
  -p            output patch format.
  -u            synonym for -p.
  --patch-with-raw
output both a patch and the diff-raw format.
  --stat        show diffstat instead of patch.
  --numstat     show numeric diffstat instead of patch.
  --patch-with-stat
output a patch and prepend its diffstat.
  --name-only   show only names of changed files.
  --name-status show names and status of changed files.
  --full-index  show full object name on index lines.
  --abbrev=<n>  abbreviate object names in diff-tree header and diff-raw.
  -R            swap input file pairs.
  -B            detect complete rewrites.
  -M            detect renames.
  -C            detect copies.
  --find-copies-harder
try unchanged files as candidate for copy detection.
  -l<n>         limit rename attempts up to <n> paths.
  -O<file>      reorder diffs according to the <file>.
  -S<string>    find filepair whose only one side contains the string.
  --pickaxe-all
show all files diff when -S is used and hit is found.
  -a  --text    treat all files as text.

Cannot close git diff-index --cached --numstat --summary HEAD... -- () at <redacted>/libexec/git-core/git-add--interactive line 183.

This happens because checkout passes the literal argument (in the
example, `HEAD...`) to diff-index which does not recognise merge-base
revs.

Fix this by using the hex of the found commit instead of the given name.
Note that "HEAD" is handled specially in run_add_interactive() so it's
explicitly not changed.

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

Documentation/config/checkout: replace sq with backticks

The modern style for Git documentation is to use backticks to quote
any command-line documenation so that it is typeset in monospace.
Replace all single quotes with backticks to conform to this.

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

userdiff: recognize 'macro_rules!' as starting a Rust function block

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

userdiff: PHP: catch "abstract" and "final" functions

PHP permits functions to be defined like

       final public function foo() { }
       abstract protected function bar() { }

but our hunk header pattern does not recognize these decorations.
Add "final" and "abstract" to the list of function modifiers.

Helped-by: Johannes Sixt <redacted>
Signed-off-by: Javier Spagnoletti <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-gui: improve dark mode support

The colors of some ttext widgets are hard-coded. These hard-coded colors
are okay with a light theme but with a dark theme some widgets are dark
colored and the hard-coded ones are still light. This defeats the
purpose of applying the theme and makes the UI look very awkward.

Remove the hard-coded colors in ttext calls and use colors from the
theme for those widgets via Text.Background and Text.Foreground from the
option database.

Similarly, the highlighting for the currently selected file(s) in the
"Staged Files" and "Unstaged Files" sections is also hard-coded. Pull
the colors for that from the current theme to make sure it is in line

Signed-off-by: Serg Tereshchenko <redacted>
Signed-off-by: Pratyush Yadav <redacted>

t5534: split stdout and stderr redirection

On atomic pushing failure with GnuPG, we expect a very specific output
in stdout due to `--porcelain` switch.

On such failure, we also write down some helpful hint into stderr
in order to help user understand what happens and how to continue from
those failures.

On a lot of system, those hint (in stderr) will be flushed first,
then those messages in stdout will be flushed. In such systems, the
current test code is fine as is.

However, we don't have such guarantee, (at least) there're some real
systems that writes those stream interleaved. On such systems, we may
see the stderr stream written in the middle of stdout stream.

Let's split those stream redirection. By splitting those stream,
the output stream will contain exactly what we want to compare,
thus, saving us a "sed" invocation.

While we're at it, change the `test_i18ncmp` to `test_cmp` because we
will never translate those messages (because of `--porcelain`).

Signed-off-by: Đoàn Trần Công Danh <redacted>
Signed-off-by: Junio C Hamano <redacted>

l10n: tr: v2.29.0 round 1

Signed-off-by: Emir Sarı <redacted>

l10n: Update Catalan translation

Signed-off-by: Jordi Mas <redacted>

l10n: git.pot: v2.29.0 round 1 (124 new, 42 removed)

Generate po/git.pot from v2.29.0-rc0 for git v2.29.0 l10n round 1.

Signed-off-by: Jiang Xin <redacted>

Git 2.29-rc0

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

Merge branch 'nl/credential-crlf'

Loosen the parser in the receiving end of the credential protocol
to allow credential helper to terminate lines with CRLF line
ending, as well as LF line ending.

* nl/credential-crlf:
  credential: treat CR/LF as line endings in the credential protocol

Merge branch 'sn/fast-import-doc'

Doc update.

* sn/fast-import-doc:
  fast-import: fix typo in documentation

Merge branch 'pb/submodule-doc-fix'

Doc update.

* pb/submodule-doc-fix:
  gitsubmodules doc: invoke 'ls-files' with '--recurse-submodules'

Merge branch 'jk/format-auto-base-when-able'

"git format-patch" learns to take "whenAble" as a possible value
for the format.useAutoBase configuration variable to become no-op
when the  automatically computed base does not make sense.

* jk/format-auto-base-when-able:
  format-patch: teach format.useAutoBase "whenAble" option

Merge branch 'jk/diff-cc-oidfind-fix'

"log -c --find-object=X" did not work well to find a merge that
involves a change to an object X from only one parent.

* jk/diff-cc-oidfind-fix:
  combine-diff: handle --find-object in multitree code path

Merge branch 'jk/refspecs-negative'

"git fetch" and "git push" support negative refspecs.

* jk/refspecs-negative:
  refspec: add support for negative refspecs

Merge branch 'rs/archive-add-file'

"git archive" learns the "--add-file" option to include untracked
files into a snapshot from a tree-ish.

* rs/archive-add-file:
  Makefile: use git-archive --add-file
  archive: add --add-file
  archive: read short blobs in archive.c::write_archive_entry()

Merge branch 'jt/keep-partial-clone-filter-upon-lazy-fetch'

The lazy fetching done internally to make missing objects available
in a partial clone incorrectly made permanent damage to the partial
clone filter in the repository, which has been corrected.

* jt/keep-partial-clone-filter-upon-lazy-fetch:
  fetch: do not override partial clone filter
  promisor-remote: remove unused variable

Merge branch 'td/submodule-update-quiet'

"git submodule update --quiet" did not squelch underlying "rebase"
and "pull" commands.

* td/submodule-update-quiet:
  submodule update: silence underlying merge/rebase with "--quiet"

Merge branch 'jk/unused'

Code cleanup.

* jk/unused:
  dir.c: drop unused "untracked" from treat_path_fast()
  sequencer: handle ignore_footer when parsing trailers
  test-advise: check argument count with argc instead of argv
  sparse-checkout: fill in some options boilerplate
  sequencer: drop repository argument from run_git_commit()
  push: drop unused repo argument to do_push()
  assert PARSE_OPT_NONEG in parse-options callbacks
  env--helper: write to opt->value in parseopt helper
  drop unused argc parameters
  convert: drop unused crlf_action from check_global_conv_flags_eol()

Merge branch 'js/cmake-vs'

Using the CMake support we added some time ago for real with Visual
Studio build revealed there were lot of usability improvements
possible, which have been carried out.

* js/cmake-vs:
  hashmap_for_each_entry(): workaround MSVC's runtime check failure #3
  cmake (Windows): recommend using Visual Studio's built-in CMake support
  cmake (Windows): initialize vcpkg/build dependencies automatically
  cmake (Windows): complain when encountering an unknown compiler
  cmake (Windows): let the `.dll` files be found when running the tests
  cmake: quote the path accurately when editing `test-lib.sh`
  cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows
  cmake: ensure that the `vcpkg` packages are found on Windows
  cmake: do find Git for Windows' shell interpreter
  cmake: ignore files generated by CMake as run in Visual Studio

Merge branch 'ma/worktree-cleanups'

Code clean-up.

* ma/worktree-cleanups:
  worktree: use skip_prefix to parse target
  worktree: rename copy-pasted variable
  worktree: update renamed variable in comment
  worktree: inline `worktree_ref()` into its only caller
  wt-status: introduce wt_status_state_free_buffers()
  wt-status: print to s->fp, not stdout
  wt-status: replace sha1 mentions with oid

Merge branch 'so/combine-diff-simplify'

Code simplification.

* so/combine-diff-simplify:
  diff: get rid of redundant 'dense' argument

Merge branch 'js/default-branch-name-part-2'

Update the tests to drop word 'master' from them.

* js/default-branch-name-part-2:
  t9902: avoid using the branch name `master`
  tests: avoid variations of the `master` branch name
  t3200: avoid variations of the `master` branch name
  fast-export: avoid using unnecessary language in a code comment
  t/test-terminal: avoid non-inclusive language

Merge branch 'pm/gitk-update'

"gitk" update.

* pm/gitk-update:
  gitk: Resize panes correctly when reducing window size
  gitk: replace tabs with spaces
  gitk: fix the context menu not appearing in the presence of submodule diffs
  gitk: Un-hide selection in areas with non-default background color
  gitk: add diff lines background colors
  gitk: be prepared to be run in a bare repository
  gitk: Preserve window dimensions on exit when not using ttk themes
  gitk: don't highlight files after submodules as submodules
  gitk: fix branch name encoding error
  gitk: rename "commit summary" to "commit reference"

Merge branch 'ds/in-merge-bases-many-optim-bug'

in_merge_bases_many(), a way to see if a commit is reachable from
any commit in a set of commits, was totally broken when the
commit-graph feature was in use, which has been corrected.

* ds/in-merge-bases-many-optim-bug:
  commit-reach: fix in_merge_bases_many bug

fast-import: fix typo in documentation

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

gitsubmodules doc: invoke 'ls-files' with '--recurse-submodules'

`git ls-files` was never taught to respect the `submodule.recurse`
configuration variable, and it is too late now to change that [1],
but still the command is mentioned in 'gitsubmodules(7)' as if it
does respect that config.

Adjust the call in 'gitsubmodules(7)' by calling 'ls-files' with the
'--recurse-submodules' option.

While at it, uniformize the capitalization in that file, and use
backticks instead of quotes for Git commands and configuration
variables.

[1] https://lore.kernel.org/git/pull.732.git.1599707259907.gitgitgadget@gmail.com/T/#u

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

Nineteenth batch

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

Merge branch 'mt/delta-base-cache-races'

A race that leads to an access to a free'd data was corrected in
the codepath that reads pack files.

* mt/delta-base-cache-races:
  packfile: fix memory leak in add_delta_base_cache()
  packfile: fix race condition on unpack_entry()

Merge branch 'jk/shortlog-group-by-trailer'

"git shortlog" has been taught to group commits by the contents of
the trailer lines, like "Reviewed-by:", "Coauthored-by:", etc.

* jk/shortlog-group-by-trailer:
  shortlog: allow multiple groups to be specified
  shortlog: parse trailer idents
  shortlog: rename parse_stdin_ident()
  shortlog: de-duplicate trailer values
  shortlog: match commit trailers with --group
  trailer: add interface for iterating over commit trailers
  shortlog: add grouping option
  shortlog: change "author" variables to "ident"

Merge branch 'jc/fmt-merge-msg-suppress-destination'

Docfix.

* jc/fmt-merge-msg-suppress-destination:
  config/fmt-merge-msg.txt: drop space in quote

Merge branch 'tb/upload-pack-filters'

Hotfix.

* tb/upload-pack-filters:
  config/uploadpack.txt: fix typo in `--filter=tree:<n>`

Merge branch 'jc/sequencer-stopped-sha-simplify'

Code simplification.

* jc/sequencer-stopped-sha-simplify:
  sequencer: stop abbreviating stopped-sha file

Merge branch 'au/complete-restore-s'

The command line completion (in contrib/) learned that "git restore
-s <TAB>" is often followed by a refname.

* au/complete-restore-s:
  completion: complete refs after 'git restore -s'
  completion: use "prev" variable instead of introducing "prevword"

Merge branch 'al/ref-filter-merged-and-no-merged'

Hotfix.

* al/ref-filter-merged-and-no-merged:
  ref-filter: plug memory leak in reach_filter()

Merge branch 'eg/mailinfo-doc-scissors'

The explanation of the "scissors line" has been clarified.

* eg/mailinfo-doc-scissors:
  Doc: show example scissors line

Merge branch 'mr/bisect-in-c-2'

Rewrite of the "git bisect" script in C continues.

* mr/bisect-in-c-2:
  bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell functions in C
  bisect: call 'clear_commit_marks_all()' in 'bisect_next_all()'
  bisect--helper: reimplement `bisect_autostart` shell function in C
  bisect--helper: introduce new `write_in_file()` function
  bisect--helper: use '-res' in 'cmd_bisect__helper' return
  bisect--helper: BUG() in cmd_*() on invalid subcommand

Merge branch 'cc/bisect-start-fix'

"git bisect start X Y", when X and Y are not valid committish
object names, should take X and Y as pathspec, but didn't.

* cc/bisect-start-fix:
  bisect: don't use invalid oid as rev when starting

Merge branch 'jc/blame-ignore-fix'

"git blame --ignore-rev/--ignore-revs-file" failed to validate
their input are valid revision, and failed to take into account
that the user may want to give an annotated tag instead of a
commit, which has been corrected.

* jc/blame-ignore-fix:
  blame: validate and peel the object names on the ignore list
  t8013: minimum preparatory clean-up

Merge branch 'jk/drop-unaligned-loads'

Compilation fix around type punning.

* jk/drop-unaligned-loads:
  Revert "fast-export: use local array to store anonymized oid"
  bswap.h: drop unaligned loads

Merge branch 'js/no-builtins-on-disk-option'

The installation procedure learned to optionally omit "git-foo"
executable files for each 'foo' built-in subcommand, which are only
required by old timers that still rely on the age old promise that
prepending "git --exec-path" output to PATH early in their script
will keep the "git-foo" calls they wrote working.

The old attempt to remove these executables from the disk failed in
the 1.6 era; it may be worth attempting again, but I think it is
worth to keep this topic separate from such a policy change to help
it graduate early.

* js/no-builtins-on-disk-option:
  ci: stop linking built-ins to the dashed versions
  Optionally skip linking/copying the built-ins
  msvc: copy the correct `.pdb` files in the Makefile target `install`

Merge branch 'ab/mediawiki-fixes'

Modernization and fixes to MediaWiki remote backend.

* ab/mediawiki-fixes:
  remote-mediawiki: use "sh" to eliminate unquoted commands
  remote-mediawiki: annotate unquoted uses of run_git()
  remote-mediawiki: convert to quoted run_git() invocation
  remote-mediawiki: provide a list form of run_git()
  remote-mediawiki tests: annotate failing tests
  remote-mediawiki: fix duplicate revisions being imported
  remote-mediawiki tests: use CLI installer
  remote-mediawiki tests: use inline PerlIO for readability
  remote-mediawiki tests: replace deprecated Perl construct
  remote-mediawiki tests: use a more idiomatic dispatch table
  remote-mediawiki tests: use "$dir/" instead of "$dir."
  remote-mediawiki tests: change `[]` to `test`
  remote-mediawiki tests: use test_cmp in tests
  remote-mediawiki tests: use a 10 character password
  remote-mediawiki tests: use the login/password variables
  remote-mediawiki doc: don't hardcode Debian PHP versions
  remote-mediawiki doc: link to MediaWiki's current version
  remote-mediawiki doc: correct link to GitHub project

credential: treat CR/LF as line endings in the credential protocol

This fix makes using Git credentials more friendly to Windows users: it
allows a credential helper to communicate using CR/LF line endings ("DOS
line endings" commonly found on Windows) instead of LF-only line endings
("Unix line endings").

Note that this changes the behavior a bit: if a credential helper
produces, say, a password with a trailing Carriage Return character,
that will now be culled even when the rest of the lines end only in Line
Feed characters, indicating that the Carriage Return was not meant to be
part of the line ending.

In practice, it seems _very_ unlikely that something like this happens.
Passwords usually need to consist of non-control characters, URLs need
to have special characters URL-encoded, and user names, well, are names.

However, it _does_ help on Windows, where CR/LF line endings are common:
as unrecognized commands are simply ignored by the credential machinery,
even a command like `quit\r` (which is clearly intended to abort) would
simply be ignored (silently) by Git.

So let's change the credential machinery to accept both CR/LF and LF
line endings.

While we do this for the credential helper protocol, we do _not_ adjust
`git credential-cache--daemon` (which won't work on Windows, anyway,
because it requires Unix sockets) nor `git credential-store` (which
writes the file `~/.git-credentials` which we consider an implementation
detail that should be opaque to the user, read: we do expect users _not_
to edit this file manually).

Signed-off-by: Nikita Leonov <redacted>
Signed-off-by: Johannes Schindelin <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge remote-tracking branch 'paulus/master' into pm/gitk-update

* paulus/master:
  gitk: Resize panes correctly when reducing window size
  gitk: replace tabs with spaces
  gitk: fix the context menu not appearing in the presence of submodule diffs
  gitk: Un-hide selection in areas with non-default background color
  gitk: add diff lines background colors
  gitk: be prepared to be run in a bare repository
  gitk: Preserve window dimensions on exit when not using ttk themes
  gitk: don't highlight files after submodules as submodules
  gitk: fix branch name encoding error
  gitk: rename "commit summary" to "commit reference"

t, doc: update tests, reference for "--force-if-includes"

Update test cases for the new option, and document its usage
and update related references.

Update test cases for the new option, and document its usage
and update related references.

 - t/t5533-push-cas.sh:
   Update test cases for "compare-and-swap" when used along with
   "--force-if-includes" helps mitigate overwrites when remote
   refs are updated in the background; allows forced updates when
   changes from remote are integrated locally.

 - Documentation:
   Add reference for the new option, configuration setting
   ("push.useForceIfIncludes") and advise messages.

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

push: parse and set flag for "--force-if-includes"

The previous commit added the necessary machinery to implement the
"--force-if-includes" protection, when "--force-with-lease" is used
without giving exact object the remote still ought to have. Surface
the feature by adding a command line option and a configuration
variable to enable it.

 - Add a flag: "TRANSPORT_PUSH_FORCE_IF_INCLUDES" to indicate that the
   new option was passed from the command line of via configuration
   settings; update command line and configuration parsers to set the
   new flag accordingly.

 - Introduce a new configuration option "push.useForceIfIncludes", which
   is equivalent to setting "--force-if-includes" in the command line.

 - Update "remote-curl" to recognize and pass this option to "send-pack"
   when enabled.

 - Update "advise" to catch the reject reason "REJECT_REF_NEEDS_UPDATE",
   set when the ref status is "REF_STATUS_REJECT_REMOTE_UPDATED" and
   (optionally) print a help message when the push fails.

 - The new option is a "no-op" in the following scenarios:
    * When used without "--force-with-lease".
    * When used with "--force-with-lease", and if the expected commit
      on the remote side is specified as an argument.

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

push: add reflog check for "--force-if-includes"

Add a check to verify if the remote-tracking ref of the local branch
is reachable from one of its "reflog" entries.

The check iterates through the local ref's reflog to see if there
is an entry for the remote-tracking ref and collecting any commits
that are seen, into a list; the iteration stops if an entry in the
reflog matches the remote ref or if the entry timestamp is older
the latest entry of the remote ref's "reflog". If there wasn't an
entry found for the remote ref, "in_merge_bases_many()" is called
to check if it is reachable from the list of collected commits.

When a local branch that is based on a remote ref, has been rewound
and is to be force pushed on the remote, "--force-if-includes" runs
a check that ensures any updates to the remote-tracking ref that may
have happened (by push from another repository) in-between the time
of the last update to the local branch (via "git-pull", for instance)
and right before the time of push, have been integrated locally
before allowing a forced update.

If the new option is passed without specifying "--force-with-lease",
or specified along with "--force-with-lease=<refname>:<expect>" it
is a "no-op".

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

gitk: Resize panes correctly when reducing window size

The resizeclistpanes and resizecdetpanes procedures attempt to keep
the horizontal proportions of the panes of the gitk window
approximately constant when the gitk window is resized.  However, if
the size is reduced enough that an existing sash position would go
outside the window, Tk moves the sash to the left to keep it inside
the window (without moving other sash positions to keep the
proportions).  This happens before these resize procedures get
control, and so they work with incorrect proportions.

To fix this, we record the sash positions we set previously and use
those previously-set sash positions rather than the current sash
positions when computing the proportions.

Signed-off-by: Paul Mackerras <redacted>

gitk: replace tabs with spaces

The source code is a mix of tabs and spaces. The indentation style
currently is four spaces per indent level but uses tabs every other
level (at eight spaces). Fix this inconsistent spacing and tabbing by
just using a space-indent for everything.

This was done mechanically by running:

$ expand -i gitk >gitk.new
$ mv gitk.new gitk

This patch should be empty with `--ignore-all-space`.

Signed-off-by: Denton Liu <redacted>
Signed-off-by: Paul Mackerras <redacted>

Merge branch 'ds/in-merge-bases-many-optim-bug' into sk/force-if-includes

* ds/in-merge-bases-many-optim-bug:
  commit-reach: fix in_merge_bases_many bug

commit-reach: fix in_merge_bases_many bug

Way back in f9b8908b (commit.c: use generation numbers for
in_merge_bases(), 2018-05-01), a heuristic was used to short-circuit
the in_merge_bases() walk. This works just fine as long as the
caller is checking only two commits, but when there are multiple,
there is a possibility that this heuristic is _very wrong_.

Some code moves since then has changed this method to
repo_in_merge_bases_many() inside commit-reach.c. The heuristic
computes the minimum generation number of the "reference" list, then
compares this number to the generation number of the "commit".

In a recent topic, a test was added that used in_merge_bases_many()
to test if a commit was reachable from a number of commits pulled
from a reflog. However, this highlighted the problem: if any of the
reference commits have a smaller generation number than the given
commit, then the walk is skipped _even if there exist some with
higher generation number_.

This heuristic is wrong! It must check the MAXIMUM generation number
of the reference commits, not the MINIMUM.

This highlights a testing gap. t6600-test-reach.sh covers many
methods in commit-reach.c, including in_merge_bases() and
get_merge_bases_many(), but since these methods either restrict to
two input commits or actually look for the full list of merge bases,
they don't check this heuristic!

Add a possible input to "test-tool reach" that tests
in_merge_bases_many() and add tests to t6600-test-reach.sh that
cover this heuristic. This includes cases for the reference commits
having generation above and below the generation of the input commit,
but also having maximum generation below the generation of the input
commit.

The fix itself is to swap min_generation with a max_generation in
repo_in_merge_bases_many().

Reported-by: Srinidhi Kaushik <redacted>
Helped-by: Johannes Schindelin <redacted>
Signed-off-by: Derrick Stolee <redacted>
Signed-off-by: Junio C Hamano <redacted>

format-patch: teach format.useAutoBase "whenAble" option

The format.useAutoBase configuration option exists to allow users to
enable '--base=auto' for format-patch by default.

This can sometimes lead to poor workflow, due to unexpected failures
when attempting to format an ancient patch:

    $ git format-patch -1 <an old commit>
    fatal: base commit shouldn't be in revision list

This can be very confusing, as it is not necessarily immediately obvious
that the user requested a --base (since this was in the configuration,
not on the command line).

We do want --base=auto to fail when it cannot provide a suitable base,
as it would be equally confusing if a formatted patch did not include
the base information when it was requested.

Teach format.useAutoBase a new mode, "whenAble". This mode will cause
format-patch to attempt to include a base commit when it can. However,
if no valid base commit can be found, then format-patch will continue
formatting the patch without a base commit.

In order to avoid making yet another branch name unusable with --base,
do not teach --base=whenAble or --base=whenable.

Instead, refactor the base_commit option to use a callback, and rely on
the global configuration variable auto_base.

This does mean that a user cannot request this optional base commit
generation from the command line. However, this is likely not too
valuable. If the user requests base information manually, they will be
immediately informed of the failure to acquire a suitable base commit.
This allows the user to make an informed choice about whether to
continue the format.

Add tests to cover the new mode of operation for --base.

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

submodule update: silence underlying merge/rebase with "--quiet"

Commands such as

    $ git pull --rebase --recurse-submodules --quiet

produce non-quiet output from the merge or rebase.  Pass the --quiet
option down when invoking "rebase" and "merge".

Also fix the parsing of git submodule update -v.

When e84c3cf3 (git-submodule.sh: accept verbose flag in cmd_update
to be non-quiet, 2018-08-14) taught "git submodule update" to take
"--quiet", it apparently did not know how ${GIT_QUIET:+--quiet}
works, and reviewers seem to have missed that setting the variable
to "0", rather than unsetting it, still results in "--quiet" being
passed to underlying commands.

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

clone: allow configurable default for `-o`/`--origin`

While the default remote name of "origin" can be changed at clone-time
with `git clone`'s `--origin` option, it was previously not possible
to specify a default value for the name of that remote.  Add support for
a new `clone.defaultRemoteName` config, with the newly-created remote
name resolved in priority order:

1. (Highest priority) A remote name passed directly to `git clone -o`
2. A `clone.defaultRemoteName=new_name` in config `git clone -c`
3. A `clone.defaultRemoteName` value set in `/path/to/template/config`,
   where `--template=/path/to/template` is provided
4. A `clone.defaultRemoteName` value set in a non-template config file
5. The default value of `origin`

Helped-by: Junio C Hamano <redacted>
Helped-by: Johannes Schindelin <redacted>
Helped-by: Derrick Stolee <redacted>
Helped-by: Andrei Rybak <redacted>
Signed-off-by: Sean Barag <redacted>
Signed-off-by: Junio C Hamano <redacted>

clone: read new remote name from remote_name instead of option_origin

In a future patch, the name of the remote created by `git clone` may
come from multiple sources.  To avoid confusion, convert most uses of
option_origin to remote_name, leaving option_origin to exclusively
represent the -o/--origin option.

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

clone: validate --origin option before use

Providing a bad origin name to `git clone` currently reports an
'invalid refspec' error instead of a more explicit message explaining
that the `--origin` option was malformed.  This behavior dates back to
since 8434c2f1 (Build in clone, 2008-04-27).  Reintroduce
validation for the provided `--origin` option, but notably _don't_
include a multi-level check (e.g. "foo/bar") that was present in the
original `git-clone.sh`.  `git remote` allows multi-level remote names
since at least 46220ca100 (remote.c: Fix overtight refspec validation,
2008-03-20), so that appears to be the desired behavior.

Helped-by: Junio C Hamano <redacted>
Helped-by: Derrick Stolee <redacted>
Helped-by: Jeff King <redacted>
Signed-off-by: Sean Barag <redacted>
Signed-off-by: Junio C Hamano <redacted>

refs: consolidate remote name validation

In preparation for a future patch, extract from remote.c a function that
validates possible remote names so that its rules can be used
consistently in other places.

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

remote: add tests for add and rename with invalid names

In preparation for a future patch that moves `builtin/remote.c`'s
remote-name validation, ensure `git remote add` and `git remote rename`
report errors when the new name isn't valid.

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

clone: use more conventional config/option layering

Parsing command-line options before reading from config required careful
handling to ensure CLI options were treated with higher priority.  Read
config first to let parsed CLI naively overwrite matching config values.

Helped-by: Junio C Hamano <redacted>
Helped-by: Johannes Schindelin <redacted>
Signed-off-by: Sean Barag <redacted>
Signed-off-by: Junio C Hamano <redacted>

refspec: add support for negative refspecs

Both fetch and push support pattern refspecs which allow fetching or
pushing references that match a specific pattern. Because these patterns
are globs, they have somewhat limited ability to express more complex
situations.

For example, suppose you wish to fetch all branches from a remote except
for a specific one. To allow this, you must setup a set of refspecs
which match only the branches you want. Because refspecs are either
explicit name matches, or simple globs, many patterns cannot be
expressed.

Add support for a new type of refspec, referred to as "negative"
refspecs. These are prefixed with a '^' and mean "exclude any ref
matching this refspec". They can only have one "side" which always
refers to the source. During a fetch, this refers to the name of the ref
on the remote. During a push, this refers to the name of the ref on the
local side.

With negative refspecs, users can express more complex patterns. For
example:

 git fetch origin refs/heads/*:refs/remotes/origin/* ^refs/heads/dontwant

will fetch all branches on origin into remotes/origin, but will exclude
fetching the branch named dontwant.

Refspecs today are commutative, meaning that order doesn't expressly
matter. Rather than forcing an implied order, negative refspecs will
always be applied last. That is, in order to match, a ref must match at
least one positive refspec, and match none of the negative refspecs.
This is similar to how negative pathspecs work.

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

combine-diff: handle --find-object in multitree code path

When doing combined diffs, we have two possible code paths:

  - a slower one which independently diffs against each parent, applies
    any filters, and then intersects the resulting paths

  - a faster one which walks all trees simultaneously

When the diff options specify that we must do certain filters, like
pickaxe, then we always use the slow path, since the pickaxe code only
knows how to handle filepairs, not the n-parent entries generated for
combined diffs.

But there are two problems with the slow path:

 1. It's slow. Running:

      git rev-list HEAD | git diff-tree --stdin -r -c

    in git.git takes ~3s on my machine. But adding "--find-object" to
    that increases it to ~6s, even though find-object itself should
    incur only a few extra oid comparisons. On linux.git, it's even
    worse: 35s versus 215s.

 2. It doesn't catch all cases where a particular path is interesting.
    Consider a merge with parent blobs X and Y for a particular path,
    and end result Z. That should be interesting according to "-c",
    because the result doesn't match either parent. And it should be
    interesting even with "--find-object=X", because "X" went away in
    the merge.

    But because we perform each pairwise diff independently, this
    confuses the intersection code. The change from X to Z is still
    interesting according to --find-object. But in the other parent we
    went from Y to Z, so the diff appears empty! That causes the
    intersection code to think that parent didn't change the path, and
    thus it's not interesting for "-c".

This patch fixes both by implementing --find-object for the multitree
code. It's a bit unfortunate that we have to duplicate some logic from
diffcore-pickaxe, but this is the best we can do for now. In an ideal
world, all of the diffcore code would stop thinking about filepairs and
start thinking about n-parent sets, and we could use the multitree walk
with all of it.

Until then, there are some leftover warts:

  - other pickaxe operations, like -S or -G, still suffer from both
    problems. These would be hard to adapt because they rely on having
    a diff_filespec() for each path to look at content. And we'd need to
    define what an n-way "change" means in each case (probably easy for
    "-S", which can compare counts, but not so clear for -G, which is
    about grepping diffs).

  - other options besides --find-object may cause us to use the slow
    pairwise path, in which case we'll go back to producing a different
    (wrong) answer for the X/Y/Z case above.

We may be able to hack around these, but I think the ultimate solution
will be a larger rewrite of the diffcore code. For now, this patch
improves one specific case but leaves the rest.

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

hashmap_for_each_entry(): workaround MSVC's runtime check failure #3

The OFFSETOF_VAR(var, member) macro is implemented in terms of
offsetof(typeof(*var), member) with compilers that know typeof(),
but its fallback implemenation compares &(var->member) and (var) and
count the distance in bytes, i.e.

    ((uintptr_t)&(var)->member - (uintptr_t)(var))

MSVC's runtime check, when fed an uninitialized 'var', flags this as
a use of an uninitialized variable (and that is legit---uninitialized
contents of 'var' is subtracted) in a debug build.

After auditing all 6 uses of OFFSETOF_VAR(), 1 of them does feed a
potentially uninitialized 'var' to the macro in the beginning of the
for() loop:

    #define hashmap_for_each_entry(map, iter, var, member) \
            for (var = hashmap_iter_first_entry_offset(map, iter, \
                                                    OFFSETOF_VAR(var, member)); \
                    var; \
                    var = hashmap_iter_next_entry_offset(iter, \
                                                    OFFSETOF_VAR(var, member)))

We can work around this by making sure that var has _some_ value
when OFFSETOF_VAR() is called.  Strictly speaking, it invites
undefined behaviour to use NULL here if we end up with pointer
comparison, but MSVC runtime seems to be happy with it, and most
other systems have typeof() and don't even need pointer comparison
fallback code.

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

cmake (Windows): recommend using Visual Studio's built-in CMake support

It is a lot more convenient to use than having to specify the
configuration in CMake manually (does not matter whether using the
command-line or CMake's GUI).

While at it, recommend using `contrib/buildsystems/out/` as build
directory also in the part that talks about running CMake manually.

Helped-by: Junio C Hamano <redacted>
Signed-off-by: Johannes Schindelin <redacted>
Signed-off-by: Junio C Hamano <redacted>

cmake (Windows): initialize vcpkg/build dependencies automatically

The idea of having CMake support in Git's source tree is to enable
contributors on Windows to start contributing with little effort. To
that end, we just added some sensible defaults that will let users open
the worktree in Visual Studio and start building.

This expects the dependencies (such as zlib) to be available already,
though. If they are not available, we expect the user to run
`compat/vcbuild/vcpkg_install.bat`.

Rather than requiring this step to be manual, detect the situation and
run it as part of the CMake configuration step.

Note that this obviously only applies to the scenario when we want to
compile in Visual Studio (i.e. with MS Visual C), not with GCC.
Therefore, we guard this new code block behind the `MSVC` conditional.

This concludes our journey to make it as effortless as possible to start
developing Git in Visual Studio: all the developer needs to do is to
clone Git's repository, open the worktree via `File>Open>Folder...` and
wait for CMake to finish configuring.

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

cmake (Windows): complain when encountering an unknown compiler

We have some custom handling regarding the link options, which are
specific to each compiler.

Therefore: let's not just continue without setting the link options if
configuring for a currently unhandled compiler, but error out.

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

cmake (Windows): let the `.dll` files be found when running the tests

Contrary to Unix-ish platforms, the dependencies' shared libraries are
not usually found in one central place. In our case, since we use
`vcpkg`, they are to be found inside the `compat/vcbuild/vcpkg/` tree.

Let's make sure that they are in the search path when running the tests.

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

cmake: quote the path accurately when editing `test-lib.sh`

By default, the build directory will be called something like
`contrib/buildsystems/out/build/x64-Debug (default)` (note the space and
the parentheses). We need to make sure that such a path is quoted
properly when editing the assignment of the `GIT_BUILD_DIR` variable.

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

cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows

We are already relying on `vcpkg` to manage our dependencies, including
`libiconv`. Let's also use the `msgfmt.exe` from there.

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

dir.c: drop unused "untracked" from treat_path_fast()

We don't use the untracked_cache_dir parameter that is passed in, but
instead look at the untracked_cache_dir inside the cached_dir struct we
are passed. It's been this way since the introduction of
treat_path_fast() in 91a2288b5f (untracked cache: record/validate dir
mtime and reuse cached output, 2015-03-08).

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

sequencer: handle ignore_footer when parsing trailers

The append_signoff() function takes an "ignore_footer"
argument, which specifies a number of bytes at the end of
the message buffer which should not be considered (they
cannot contain trailers, and the trailer is spliced in
before them).

But to find the existing trailers, it calls into
has_conforming_trailer(). That function takes an
ignore_footer parameter, but since 967dfd4d56 (sequencer:
use trailer's trailer layout, 2016-11-02) the parameter is
completely ignored.

The trailer interface we're using takes a single string,
with no option to tell it to use part of the string.
However, since we have a mutable strbuf, we can work around
this by simply overwriting (and later restoring) the
boundary with a NUL.

I'm not sure if this can actually trigger a bug in practice.
It's easy to get a non-zero ignore_footer by doing something
like this:

  git commit -F - --cleanup=verbatim <<-EOF
  subject

  body

Signed-off-by: me
  # this looks like a comment, but is actually in the
  # message! That makes the earlier s-o-b fake.
  EOF

  git commit --amend -s

There git-commit calls ignore_non_trailer() to count up the
"#" cruft, which becomes the ignore_footer header. But it
works even without this patch! That's because the trailer
code _also_ calls ignore_non_trailer() and skips the cruft,
too. So it happens to work because the only callers with a
non-zero ignore_footer are using the exact same function
that the trailer parser uses internally.

And that seems true for all of the current callers, but
there's nothing guaranteeing it. We're better off only
feeding the correct buffer to the trailer code in the first
place.

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

test-advise: check argument count with argc instead of argv

We complain if "test-tool advise" is not given an argument, but we
quietly ignore any additional arguments it receives. Let's instead check
that we got the expected number. As a bonus, this silences
-Wunused-parameter, which notes that we don't ever look at argc.

While we're here, we can also fix the indentation in the conditional.

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

sparse-checkout: fill in some options boilerplate

The sparse-checkout passes along argv and argc to its sub-command helper
functions. Many of these sub-commands do not yet take any command-line
options, and ignore those parameters.

Let's instead add empty option lists and make sure we call
parse_options(). That will give a useful error message for something
like:

  git sparse-checkout list --nonsense

which currently just silently ignores the unknown option.

As a bonus, it also silences some -Wunused-parameter warnings.

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

sequencer: drop repository argument from run_git_commit()

When we switched to using an external git-commit call in b0a3186140
(sequencer: simplify root commit creation, 2019-08-19), this function
didn't need to care about the repository object any more.

Arguably we could be passing along the repository path to the external
git-commit by using "--git-dir=r->path" here. But for the most part the
sequencer code relies on sub-process finding the same repository we're
already in (using the same environment variables or discovery process we
did). But we don't have a convenient interface for doing so, and there's
no indication that we need to. Let's just drop the unused parameter for
now.

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

push: drop unused repo argument to do_push()

We stopped using the "repo" argument in 8e4c8af058 (push: disallow --all
and refspecs when remote.<name>.mirror is set, 2019-09-02), which moved
the pushremote handling to its caller.

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

assert PARSE_OPT_NONEG in parse-options callbacks

In the spirit of 517fe807d6 (assert NOARG/NONEG behavior of
parse-options callbacks, 2018-11-05), let's cover some parse-options
callbacks which expect to be used with PARSE_OPT_NONEG but don't
explicitly assert that this is the case. These callbacks are all used
correctly in the current code, but this will help document their
expectations and future-proof the code.

As a bonus, it also silences -Wunused-parameters (these were added since
the initial sweep of 517fe807d6, and we can't yet turn on
-Wunused-parameters to remind people because it has too many existing
false positives).

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

env--helper: write to opt->value in parseopt helper

We use OPT_CALLBACK_F() to call the option_parse_type() callback,
passing it the address of "cmdmode" as the value to write to. But the
callback doesn't look at opt->value at all, and instead writes to a
global variable.

This works out because that's the same global variable we happen to pass
in, but it's rather confusing.  Let's use the passed-in value instead.
We'll also make "cmdmode" a local variable of the main function,
ensuring we can't make the same mistake again.

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

drop unused argc parameters

Many functions take an argv/argc pair, but never actually look at argc.
This makes it useless at best (we use the NULL sentinel in argv to find
the end of the array), and misleading at worst (what happens if the argc
count does not match the argv NULL?).

In each of these instances, the argv NULL does match the argc count, so
there are no bugs here. But let's tighten the interfaces to make it
harder to get wrong (and to reduce some -Wunused-parameter complaints).

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

convert: drop unused crlf_action from check_global_conv_flags_eol()

The crlf_action parameter hasn't been used since a0ad53c181 (convert:
Correct NNO tests and missing `LF will be replaced by CRLF`,
2016-08-13), where that part of the function was hoisted out to a
separate will_convert_lf_to_crlf() helper. Let's drop the useless
parameter.

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

Eighteenth batch

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

Merge branch 'ah/pull'

Earlier we taught "git pull" to warn when the user does not say the
histories need to be merged, rebased or accepts only fast-
forwarding, but the warning triggered for those who have set the
pull.ff configuration variable.

* ah/pull:
  pull: don't warn if pull.ff has been set

Merge branch 'tg/range-diff-same-file-fix'

"git range-diff" showed incorrect diffstat, which has been
corrected.

* tg/range-diff-same-file-fix:
  diff: fix modified lines stats with --stat and --numstat

Merge branch 'jc/t1506-rev-parse-leaves-range-endpoint-unpeeled'

Test update.

* jc/t1506-rev-parse-leaves-range-endpoint-unpeeled:
  t1506: rev-parse A..B and A...B

Merge branch 'dl/zero-oid-in-hooks'

Adjust sample hooks for hash algorithm other than SHA-1.

* dl/zero-oid-in-hooks:
  hooks--update.sample: use hash-agnostic zero OID
  hooks--pre-push.sample: use hash-agnostic zero OID
  hooks--pre-push.sample: modernize script

Merge branch 'jk/make-protocol-v2-the-default'

The transport protocol v2 has become the default again.

* jk/make-protocol-v2-the-default:
  protocol: re-enable v2 protocol by default