t1300: add test for urlmatch with multiple wildcards

Our urlmatch code handles multiple wildcards, but we don't currently
have a test that checks this code path. Add a test that we handle this
case correctly to avoid any regressions.

Signed-off-by: brian m. carlson <bk2204@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mailmap: add an additional email address for brian m. carlson

To more accurately track the provenance of contributions, brian uses a
work email address for commits created at work. Add this email address
to .mailmap so that contributions are properly attributed to the same
person.

Signed-off-by: brian m. carlson <bk2204@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

stash push: support the --pathspec-from-file option

Decisions taken for simplicity:
1) For now, `--pathspec-from-file` is declared incompatible with
   `--patch`, even when <file> is not `-`. Such use case is not
   really expected.
2) It is not allowed to pass pathspec in both args and file.

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

stash: eliminate crude option parsing

Eliminate crude option parsing and rely on real parsing instead, because
1) Crude parsing is crude, for example it's not capable of
   handling things like `git stash -m Message`
2) Adding options in two places is inconvenient and prone to bugs

As a side result, the case of `git stash -m Message` gets fixed.
Also give a good error message instead of just throwing usage at user.

----

Some review of what's been happening to this code:

Before [1], `git-stash.sh` only verified that all args begin with `-` :

# The default command is "push" if nothing but options are given
seen_non_option=
for opt
do
case "$opt" in
--) break ;;
-*) ;;
*) seen_non_option=t; break ;;
esac
done

Later, [1] introduced the duplicate code I'm now removing, also making
the previous test more strict by white-listing options.

----

[1] Commit 40af1468 ("stash: convert `stash--helper.c` into `stash.c`" 2019-02-26)

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

doc: stash: synchronize <pathspec> description

This patch continues the effort that is already applied to
`git commit`, `git reset`, `git checkout` etc.

1) Added reference to 'linkgit:gitglossary[7]'.
2) Fixed mentions of incorrectly plural "pathspecs".

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

doc: stash: document more options

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

doc: stash: split options from description (2)

Together with the previous patch, this brings docs for `git stash` to
the common layout used for most other commands (see for example docs
for `git add`, `git commit`, `git checkout`, `git reset`) where all
options are documented in a separate list.

After some thinking and having a look at docs for `git svn` and
`git `submodule`, I have arrived at following conclusions:
  * Options should be described in a list rather then text to
    facilitate lookup for user.
  * Single list is better then multiple lists because it avoids
    copy&pasting descriptions between subcommands (or, without
    copy&pasting, user will have to look up missing options in other
    subcommands).
  * As a consequence, commands section should only give brief info and
    list possible options. Since options have good enough names, user
will only need to look up the "interesting" options.
  * Every option should list which subcommands support it.

I have decided to use alphabetical sorting in the list of options to
facilitate lookup for user.

There is some text editing done to make old descriptions better fit
into the list-style format.

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

doc: stash: split options from description (1)

This patch moves blocks of text as-is to make it easier to review the
next patch.

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

rm: support the --pathspec-from-file option

Decisions taken for simplicity:
1) It is not allowed to pass pathspec in both args and file.

Adjustments were needed for `if (!argc)` block:

This code actually means "pathspec is not present". Previously, pathspec
could only come from commandline arguments, so testing for `argc` was a
valid way of testing for the presence of pathspec. But this is no longer
true with `--pathspec-from-file`.

During the entire `--pathspec-from-file` story, I tried to keep its
behavior very close to giving pathspec on commandline, so that switching
from one to another doesn't involve any surprises.

However, throwing usage at user in the case of empty
`--pathspec-from-file` would puzzle because there's nothing wrong with
"usage" (that is, argc/argv array).

On the other hand, throwing usage in the old case also feels bad to me.
While it's less of a puzzle, I (as user) never liked the experience of
comparing my commandline to "usage", trying to spot a difference. Since
it's already known what the error is, it feels a lot better to give that
specific error to user.

Judging from [1] it doesn't seem that showing usage in this case was
important (the patch was to avoid segfault), and it doesn't fit into how
other commands react to empty pathspec (see for example `git add` with a
custom message).

Therefore, I decided to show new error text in both cases. In order to
continue testing for error early, I moved `parse_pathspec()` higher. Now
it happens before `read_cache()` / `hold_locked_index()` /
`setup_work_tree()`, which shouldn't cause any issues.

[1] Commit 7612a1ef ("git-rm: honor -n flag" 2006-06-09)

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

merge-recursive: fix the refresh logic in update_file_flags

If we need to delete a higher stage entry in the index to place the file
at stage 0, then we'll lose that file's stat information.  In such
situations we may still be able to detect that the file on disk is the
version we want (as noted by our comment in the code:
  /* do not overwrite file if already present */
), but we do still need to update the mtime since we are creating a new
cache_entry for that file.  Update the logic used to determine whether
we refresh a file's mtime.

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

t3433: new rebase testcase documenting a stat-dirty-like failure

A user discovered a case where they had a stack of 20 simple commits to
rebase, and the rebase would succeed in picking the first commit and
then error out with a pair of "Could not execute the todo command" and
"Your local changes to the following files would be overwritten by
merge" messages.

Their steps actually made use of the -i flag, but I switched it over to
-m to make it simpler to trigger the bug.  With that flag, it bisects
back to commit 68aa495b590d (rebase: implement --merge via the
interactive machinery, 2018-12-11), but that's misleading.  If you
change the -m flag to --keep-empty, then the problem persists and will
bisect back to 356ee4659bb5 (sequencer: try to commit without forking
'git commit', 2017-11-24)

After playing with the testcase for a bit, I discovered that added
--exec "sleep 1" to the command line makes the rebase succeed, making me
suspect there is some kind of discard and reloading of caches that lead
us to believe that something is stat dirty, but I didn't succeed in
digging any further than that.

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

bisect: libify `bisect_next_all`

Since we want to get rid of git-bisect.sh, it would be necessary to
convert those exit() calls to return statements so that errors can be
reported.

Emulate try catch in C by converting `exit(<positive-value>)` to
`return <negative-value>`. Follow POSIX conventions to return
<negative-value> to indicate error.

All the functions calling `bisect_next_all()` are already able to
handle return values from it.

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com>
Signed-off-by: Miriam Rubio <mirucam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: libify `handle_bad_merge_base` and its dependents

Since we want to get rid of git-bisect.sh, it would be necessary to
convert those exit() calls to return statements so that errors can be
reported.

Emulate try catch in C by converting `exit(<positive-value>)` to
`return <negative-value>`. Follow POSIX conventions to return
<negative-value> to indicate error.

Update all callers to handle the error returns.

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com>
Signed-off-by: Miriam Rubio <mirucam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: libify `check_good_are_ancestors_of_bad` and its dependents

Since we want to get rid of git-bisect.sh, it would be necessary to
convert those exit() calls to return statements so that errors can be
reported.

Emulate try catch in C by converting `exit(<positive-value>)` to
`return <negative-value>`. Follow POSIX conventions to return
<negative-value> to indicate error.

Code that turns BISECT_INTERNAL_SUCCESS_MERGE_BASE (-11)
 to BISECT_OK (0) from `check_good_are_ancestors_of_bad()` has been moved to
`cmd_bisect__helper()`.

Update all callers to handle the error returns.

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Mentored by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com>
Signed-off-by: Miriam Rubio <mirucam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: libify `check_merge_bases` and its dependents

Since we want to get rid of git-bisect.sh, it would be necessary to
convert those exit() calls to return statements so that errors can be
reported.

Emulate try catch in C by converting `exit(<positive-value>)` to
`return <negative-value>`. Follow POSIX conventions to return
<negative-value> to indicate error.

In `check_merge_bases()` there is an early success special case,
so we have introduced special error code
BISECT_INTERNAL_SUCCESS_MERGE_BASE (-11) which indicates early
success. This BISECT_INTERNAL_SUCCESS_MERGE_BASE is converted back
to BISECT_OK (0) in `check_good_are_ancestors_of_bad()`.

Update all callers to handle the error returns.

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Mentored by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com>
Signed-off-by: Miriam Rubio <mirucam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: libify `bisect_checkout`

Since we want to get rid of git-bisect.sh, it would be necessary to
convert those exit() calls to return statements so that errors can be
reported.

Emulate try catch in C by converting `exit(<positive-value>)` to
`return <negative-value>`. Follow POSIX conventions to return
<negative-value> to indicate error.

Turn `exit()` to `return` calls in `bisect_checkout()`.
Changes related to return values have no bad side effects on the
code that calls `bisect_checkout()`.

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com>
Signed-off-by: Miriam Rubio <mirucam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: libify `exit_if_skipped_commits` to `error_if_skipped*` and its dependents

Since we want to get rid of git-bisect.sh, it would be necessary to
convert those exit() calls to return statements so that errors can be
reported.

Emulate try catch in C by converting `exit(<positive-value>)` to
`return <negative-value>`. Follow POSIX conventions to return
<negative-value> to indicate error.

Update all callers to handle the error returns.

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com>
Signed-off-by: Miriam Rubio <mirucam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect--helper: return error codes from `cmd_bisect__helper()`

Since we want to get rid of git-bisect.sh, it would be necessary
to convert bisect.c exit() calls to return statements so
that errors can be reported. Let's prepare for that by making
it possible to return different error codes than just 0 or 1.

Different error codes might enable a bisecting script calling the
bisect command that uses this function to do different things
depending on the exit status of the bisect command.

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com>
Signed-off-by: Miriam Rubio <mirucam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: add enum to represent bisect returning codes

Since we want to get rid of git-bisect.sh, it would be necessary to
convert those exit() calls to return statements so that errors can be
reported.

Create an enum called `bisect_error` with the bisecting return codes
to use in `bisect.c` libification process.

Change bisect_next_all() to make it return this enum.

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Miriam Rubio <mirucam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect--helper: introduce new `decide_next()` function

Let's refactor code from bisect_next_check() into a new
decide_next() helper function.

This removes some goto statements and makes the code simpler,
clearer and easier to understand.

While at it `bad_ref` and `good_glob` are not const any more
to void casting them inside `free()`.

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com>
Signed-off-by: Miriam Rubio <mirucam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: use the standard 'if (!var)' way to check for 0

Instead of using 'var == 0' in an if condition, let's use '!var' and
make 'bisect.c' more consistent with the rest of the code.

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Miriam Rubio <mirucam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect--helper: change `retval` to `res`

Let's rename variable retval to res, so that variable names
in bisect--helper.c are more consistent.

After this change, there are 110 occurrences of res in the file
and zero of retval, while there were 26 instances of retval before.

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com>
Signed-off-by: Miriam Rubio <mirucam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect--helper: convert `vocab_*` char pointers to char arrays

Instead of using a pointer that points at a constant string,
just give name directly to the constant string; this way, we
do not have to allocate a pointer variable in addition to
the string we want to use.

Let's convert `vocab_bad` and `vocab_good` char pointers to char arrays.

Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Miriam Rubio <mirucam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

check-ignore: fix documentation and implementation to match

check-ignore has two different modes, and neither of these modes has an
implementation that matches the documentation.  These modes differ in
whether they just print paths or whether they also print the final
pattern matched by the path.  The fix is different for both modes, so
I'll discuss both separately.

=== First (default) mode ===

The first mode is documented as:

    For each pathname given via the command-line or from a file via
    --stdin, check whether the file is excluded by .gitignore (or other
    input files to the exclude mechanism) and output the path if it is
    excluded.

However, it fails to do this because it did not account for negated
patterns.  Commands other than check-ignore verify exclusion rules via
calling

   ... -> treat_one_path() -> is_excluded() -> last_matching_pattern()

while check-ignore has a call path of the form:

   ... -> check_ignore()                    -> last_matching_pattern()

The fact that the latter does not include the call to is_excluded()
means that it is susceptible to to messing up negated patterns (since
that is the only significant thing is_excluded() adds over
last_matching_pattern()).  Unfortunately, we can't make it just call
is_excluded(), because the same codepath is used by the verbose mode
which needs to know the matched pattern in question.  This brings us
to...

=== Second (verbose) mode ===

The second mode, known as verbose mode, references the first in the
documentation and says:

    Also output details about the matching pattern (if any) for each
    given pathname. For precedence rules within and between exclude
    sources, see gitignore(5).

The "Also" means it will print patterns that match the exclude rules as
noted for the first mode, and also print which pattern matches.  Unless
more information is printed than just pathname and pattern (which is not
done), this definition is somewhat ill-defined and perhaps even
self-contradictory for negated patterns: A path which matches a negated
exclude pattern is NOT excluded and thus shouldn't be printed by the
former logic, while it certainly does match one of the explicit patterns
and thus should be printed by the latter logic.

=== Resolution ==

Since the second mode exists to find out which pattern matches given
paths, and showing the user a pattern that begins with a '!' is
sufficient for them to figure out whether the pattern is excluded, the
existing behavior is desirable -- we just need to update the
documentation to match the implementation (i.e. it is about printing
which pattern is matched by paths, not about showing which paths are
excluded).

For the first or default mode, users just want to know whether a pattern
is excluded.  As such, the existing documentation is desirable; change
the implementation to match the documented behavior.

Finally, also adjust a few tests in t0008 that were caught up by this
discrepancy in how negated paths were handled.

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

doc-diff: use single-colon rule in rendering Makefile

When rendering the troff manpages to text via "man", we create an ad-hoc
Makefile and feed it to "make". The purpose here is two-fold:

  - reuse results from a prior interrupted render of the same tree

  - use make's -j option to build in parallel

But the second part doesn't seem to work (at least with my version of
GNU make, 4.2.1). It just runs one render at a time.

We use a double-colon "all" rule for each file, like:

  all:: foo
  foo:
    ...actual render recipe...
  all:: bar
  bar:
    ...actual render recipe...
  ...and so on...

And it's this double-colon that seems to inhibit the parallelism. We can
just switch to a regular single-colon rule. Even though we do have
multiple rules for "all" here, we don't have any recipe to execute for
"all" (we only care about triggering its dependencies), so the
distinction is irrelevant.

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

doc/config/push: use longer "--" line for preformatted example

The example for the push.pushOption config tries to create a
preformatted section, but uses only two dashes in its "--" line. In
AsciiDoc this is an "open block", with no type; the lines end up jumbled
because they're formatted as paragraphs. We need four or more dashes to
make it a "listing block" that will respect the linebreaks.

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

rev-list --count: comment on the use of count_right++

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

Merge branch 'py/missing-bracket'

Fix an error popping up because of an unmatched closed bracket.

* py/missing-bracket:
  git-gui: add missing close bracket

The sixth batch for 2.26

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

Merge branch 'es/outside-repo-errmsg-hints'

Error message clarification.

* es/outside-repo-errmsg-hints:
  prefix_path: show gitdir when arg is outside repo

Merge branch 'jk/doc-credential-helper'

Docfix.

* jk/doc-credential-helper:
  doc: move credential helper info into gitcredentials(7)

Merge branch 'js/mingw-open-in-gdb'

Dev support.

* js/mingw-open-in-gdb:
  mingw: add a helper function to attach GDB to the current process

Merge branch 'js/test-unc-fetch'

Test updates.

* js/test-unc-fetch:
  t5580: test cloning without file://, test fetching via UNC paths

Merge branch 'js/test-avoid-pipe'

Test clean-up.

* js/test-avoid-pipe:
  t9001, t9116: avoid pipes

Merge branch 'js/test-write-junit-xml-fix'

Testfix.

* js/test-write-junit-xml-fix:
  tests: fix --write-junit-xml with subshells

Merge branch 'jk/mailinfo-cleanup'

Code clean-up.

* jk/mailinfo-cleanup:
  mailinfo: factor out some repeated header handling
  mailinfo: be more liberal with header whitespace
  mailinfo: simplify parsing of header values
  mailinfo: treat header values as C strings

Merge branch 'mr/show-config-scope'

"git config" learned to show in which "scope", in addition to in
which file, each config setting comes from.

* mr/show-config-scope:
  config: add '--show-scope' to print the scope of a config value
  submodule-config: add subomdule config scope
  config: teach git_config_source to remember its scope
  config: preserve scope in do_git_config_sequence
  config: clarify meaning of command line scoping
  config: split repo scope to local and worktree
  config: make scope_name non-static and rename it
  t1300: create custom config file without special characters
  t1300: fix over-indented HERE-DOCs
  config: fix typo in variable name

Merge branch 'rs/strbuf-insertstr'

Code clean-up.

* rs/strbuf-insertstr:
  mailinfo: don't insert header prefix for handle_content_type()
  strbuf: add and use strbuf_insertstr()

Merge branch 'rs/parse-options-concat-dup'

Code clean-up.

* rs/parse-options-concat-dup:
  parse-options: simplify parse_options_dup()
  parse-options: const parse_options_concat() parameters
  parse-options: factor out parse_options_count()
  parse-options: use COPY_ARRAY in parse_options_concat()

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

Preparation for SHA-256 migration continues.

* bc/hash-independent-tests-part-8: (21 commits)
  t6024: update for SHA-256
  t6006: make hash size independent
  t6000: abstract away SHA-1-specific constants
  t5703: make test work with SHA-256
  t5607: make hash size independent
  t5318: update for SHA-256
  t5515: make test hash independent
  t5321: make test hash independent
  t5313: make test hash independent
  t5309: make test hash independent
  t5302: make hash size independent
  t4060: make test work with SHA-256
  t4211: add test cases for SHA-256
  t4211: move SHA-1-specific test cases into a directory
  t4013: make test hash independent
  t3311: make test work with SHA-256
  t3310: make test work with SHA-256
  t3309: make test work with SHA-256
  t3308: make test work with SHA-256
  t3206: make hash size independent
  ...

Merge branch 'rs/name-rev-memsave'

Memory footprint and performance of "git name-rev" has been
improved.

* rs/name-rev-memsave:
  name-rev: sort tip names before applying
  name-rev: release unused name strings
  name-rev: generate name strings only if they are better
  name-rev: pre-size buffer in get_parent_name()
  name-rev: factor out get_parent_name()
  name-rev: put struct rev_name into commit slab
  name-rev: don't _peek() in create_or_update_name()
  name-rev: don't leak path copy in name_ref()
  name-rev: respect const qualifier
  name-rev: remove unused typedef
  name-rev: rewrite create_or_update_name()

git-gui: add missing close bracket

In d9c6469 (git-gui: update status bar to track operations, 2019-12-01),
the status bar was refactored to allow multiple overlapping operations.

Since the refactor changed the status bar interface, all callsites had
to be refactored to use the new interface. During that refactoring, this
closing bracket was missed. This leads to an error message popping up
when doing 'Branch->Reset...'.

Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>

Merge branch 'cs/german-translation'

Update the German translation and extend glossary.

* cs/german-translation:
  git-gui: update German translation
  git-gui: extend translation glossary template with more terms
  git-gui: update pot template and German translation to current source code

git-gui: update German translation

Update German translation (glossary and final translation) with
recent additions, but also switch several terms from uncommon
translations back to English vocabulary.

This most prominently concerns "commit" (noun, verb), "repository",
"branch", and some more. These uncommon translations have been introduced
long ago and never been changed since. In fact, the whole German
translation here hasn't been touched for a long time. However, in German
literature and magazines, git-gui is regularly noted for its uncommon
choice of translated vocabulary. This somewhat distracts from the actual
benefits of this tool. So it is probably better to abandon the uncommon
translations and rather stick to the common English vocabulary in git
version control.

Signed-off-by: Christian Stimming <christian@cstimming.de>
Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>

git-gui: extend translation glossary template with more terms

The English glossary template was missing some terms, some of them
not only for git-gui, but also gitk and/or git core. Many such terms
have been added.

Also, the list has been sorted alphabetically so that comparison to
other glossary lists are easier.

Signed-off-by: Christian Stimming <christian@cstimming.de>
Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>

git-gui: update pot template and German translation to current source code

No content changes so far, only the preparation for subsequent edits.

Signed-off-by: Christian Stimming <christian@cstimming.de>
Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>

Sync with 2.25.1

Git 2.25.1

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

rebase: rename the two primary rebase backends

Two related changes, with separate rationale for each:

Rename the 'interactive' backend to 'merge' because:
  * 'interactive' as a name caused confusion; this backend has been used
    for many kinds of non-interactive rebases, and will probably be used
    in the future for more non-interactive rebases than interactive ones
    given that we are making it the default.
  * 'interactive' is not the underlying strategy; merging is.
  * the directory where state is stored is not called
    .git/rebase-interactive but .git/rebase-merge.

Rename the 'am' backend to 'apply' because:
  * Few users are familiar with git-am as a reference point.
  * Related to the above, the name 'am' makes sentences in the
    documentation harder for users to read and comprehend (they may read
    it as the verb from "I am"); avoiding this difficult places a large
    burden on anyone writing documentation about this backend to be very
    careful with quoting and sentence structure and often forces
    annoying redundancy to try to avoid such problems.
  * Users stumble over pronunciation ("am" as in "I am a person not a
    backend" or "am" as in "the first and thirteenth letters in the
    alphabet in order are "A-M"); this may drive confusion when one user
    tries to explain to another what they are doing.
  * While "am" is the tool driving this backend, the tool driving git-am
    is git-apply, and since we are driving towards lower-level tools
    for the naming of the merge backend we may as well do so here too.
  * The directory where state is stored has never been called
    .git/rebase-am, it was always called .git/rebase-apply.

For all the reasons listed above:
  * Modify the documentation to refer to the backends with the new names
  * Provide a brief note in the documentation connecting the new names
    to the old names in case users run across the old names anywhere
    (e.g. in old release notes or older versions of the documentation)
  * Change the (new) --am command line flag to --apply
  * Rename some enums, variables, and functions to reinforce the new
    backend names for us as well.

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

rebase: change the default backend from "am" to "merge"

The am-backend drops information and thus limits what we can do:

  * lack of full tree information from the original commits means we
    cannot do directory rename detection and warn users that they might
    want to move some of their new files that they placed in old
    directories to prevent their becoming orphaned.[1]
  * reduction in context from only having a few lines beyond those
    changed means that when context lines are non-unique we can apply
    patches incorrectly.[2]
  * lack of access to original commits means that conflict marker
    annotation has less information available.
  * the am backend has safety problems with an ill-timed interrupt.

Also, the merge/interactive backend have far more abilities, appear to
currently have a slight performance advantage[3] and have room for more
optimizations than the am backend[4] (and work is underway to take
advantage of some of those possibilities).

[1] https://lore.kernel.org/git/xmqqh8jeh1id.fsf@gitster-ct.c.googlers.com/
[2] https://lore.kernel.org/git/CABPp-BGiu2nVMQY_t-rnFR5GQUz_ipyEE8oDocKeO+h+t4Mn4A@mail.gmail.com/
[3] https://public-inbox.org/git/CABPp-BF=ev03WgODk6TMQmuNoatg2kiEe5DR__gJ0OTVqHSnfQ@mail.gmail.com/
[4] https://lore.kernel.org/git/CABPp-BGh7yW69QwxQb13K0HM38NKmQif3A6C6UULEKYnkEJ5vA@mail.gmail.com/

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

rebase: make the backend configurable via config setting

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

rebase tests: repeat some tests using the merge backend instead of am

In order to ensure the merge/interactive backend gets similar coverage
to the am one, add some tests for cases where previously only the am
backend was tested.

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

rebase tests: mark tests specific to the am-backend with --am

We have many rebase tests in the testsuite, and often the same test is
repeated multiple times just testing different backends.  For those
tests that were specifically trying to test the am backend, add the --am
flag.

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

rebase: drop '-i' from the reflog for interactive-based rebases

A large variety of rebase types are supported by the interactive
machinery, not just the explicitly interactive ones.  These all share
the same code and write the same reflog messages, but the "-i" moniker
in those messages doesn't really have much meaning.  It also becomes
somewhat distracting once we switch the default from the am-backend to
the interactive one.  Just remove the "-i" from these messages.

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

git-prompt: change the prompt for interactive-based rebases

In the past, we had different prompts for different types of rebases:
   REBASE: for am-based rebases
   REBASE-m: for merge-based rebases
   REBASE-i: for interactive-based rebases

It's not clear why this distinction was necessary or helpful; when the
prompt was added in commit e75201963f67 ("Improve bash prompt to detect
various states like an unfinished merge", 2007-09-30), it simply added
these three different types.  Perhaps there was a useful purpose back
then, but there have been some changes:

  * The merge backend was deleted after being implemented on top of the
    interactive backend, causing the prompt for merge-based rebases to
    change from REBASE-m to REBASE-i.
  * The interactive backend is used for multiple different types of
    non-interactive rebases, so the "-i" part of the prompt doesn't
    really mean what it used to.
  * Rebase backends have gained more abilities and have a great deal of
    overlap, sometimes making it hard to distinguish them.
  * Behavioral differences between the backends have also been ironed
    out.
  * We want to change the default backend from am to interactive, which
    means people would get "REBASE-i" by default if we didn't change
    the prompt, and only if they specified --am or --whitespace or -C
    would they get the "REBASE" prompt.
  * In the future, we plan to have "--whitespace", "-C", and even "--am"
    run the interactive backend once it can handle everything the
    am-backend can.

For all these reasons, make the prompt for any type of rebase just be
"REBASE".

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

rebase: add an --am option

Currently, this option doesn't do anything except error out if any
options requiring the interactive-backend are also passed.  However,
when we make the default backend configurable later in this series, this
flag will provide a way to override the config setting.

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

rebase: move incompatibility checks between backend options a bit earlier

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

git-rebase.txt: add more details about behavioral differences of backends

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

rebase: allow more types of rebases to fast-forward

In the past, we dis-allowed rebases using the interactive backend from
performing a fast-forward to short-circuit the rebase operation.  This
made sense for explicitly interactive rebases and some implicitly
interactive rebases, but certainly became overly stringent when the
merge backend was re-implemented via the interactive backend.

Just as the am-based rebase has always had to disable the fast-forward
based on a variety of conditions or flags (e.g. --signoff, --whitespace,
etc.), we need to do the same but now with a few more options.  However,
continuing to use REBASE_FORCE for tracking this is problematic because
the interactive backend used it for a different purpose.  (When
REBASE_FORCE wasn't set, the interactive backend would not fast-forward
the whole series but would fast-forward individual "pick" commits at the
beginning of the todo list, and then a squash or something would cause
it to start generating new commits.)  So, introduce a new
allow_preemptive_ff flag contained within cmd_rebase() and use it to
track whether we are going to allow a pre-emptive fast-forward that
short-circuits the whole rebase.

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

t3432: make these tests work with either am or merge backends

t3432 had several stress tests for can_fast_forward(), whose intent was
to ensure we were using the optimization of just fast forwarding when
possible.  However, these tests verified that fast forwards had happened
based on the output that rebase printed to the terminal.  We can instead
test more directly that we actually fast-forwarded by checking the
reflog, which also has the side effect of making the tests applicable
for the merge/interactive backend.

This change does lose the distinction between "noop" and "noop-force",
but as stated in commit c9efc216830f ("t3432: test for --no-ff's
interaction with fast-forward", 2019-08-27) which introduced that
distinction: "These tests aren't supposed to endorse the status quo,
just test for what we're currently doing.".

This change does not actually run these tests with the merge/interactive
backend; instead this is just a preparatory commit.  A subsequent commit
which fixes can_fast_forward() to work with that backend will then also
change t3432 to add tests of that backend as well.

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

rebase: fix handling of restrict_revision

restrict_revision in the original shell script was an excluded revision
range.  It is also treated that way by the am-backend.  In the
conversion from shell to C (see commit 6ab54d17be3f ("rebase -i:
implement the logic to initialize $revisions in C", 2018-08-28)), the
interactive-backend accidentally treated it as a positive revision
rather than a negated one.

This was missed as there were no tests in the testsuite that tested an
interactive rebase with fork-point behavior.

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

rebase: make sure to pass along the quiet flag to the sequencer

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

rebase, sequencer: remove the broken GIT_QUIET handling

The GIT_QUIET environment variable was used to signal the non-am
backends that the rebase should perform quietly.  The preserve-merges
backend does not make use of the quiet flag anywhere (other than to
write out its state whenever it writes state), and this mechanism was
broken in the conversion from shell to C.  Since this environment
variable was specifically designed for scripts and the only backend that
would still use it is no longer a script, just gut this code.

A subsequent commit will fix --quiet for the interactive/merge backend
in a different way.

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

t3406: simplify an already simple test

When the merge backend was re-implemented on top of the interactive
backend, the output of rebase --merge changed a little.  This change
allowed this test to be simplified, though it wasn't noticed until now.
Simplify the testcase a little.

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

rebase (interactive-backend): fix handling of commits that become empty

As established in the previous commit and commit b00bf1c9a8dd
(git-rebase: make --allow-empty-message the default, 2018-06-27), the
behavior for rebase with different backends in various edge or corner
cases is often more happenstance than design.  This commit addresses
another such corner case: commits which "become empty".

A careful reader may note that there are two types of commits which would
become empty due to a rebase:

  * [clean cherry-pick] Commits which are clean cherry-picks of upstream
    commits, as determined by `git log --cherry-mark ...`.  Re-applying
    these commits would result in an empty set of changes and a
    duplicative commit message; i.e. these are commits that have
    "already been applied" upstream.

  * [become empty] Commits which are not empty to start, are not clean
    cherry-picks of upstream commits, but which still become empty after
    being rebased.  This happens e.g. when a commit has changes which
    are a strict subset of the changes in an upstream commit, or when
    the changes of a commit can be found spread across or among several
    upstream commits.

Clearly, in both cases the changes in the commit in question are found
upstream already, but the commit message may not be in the latter case.

When cherry-mark can determine a commit is already upstream, then
because of how cherry-mark works this means the upstream commit message
was about the *exact* same set of changes.  Thus, the commit messages
can be assumed to be fully interchangeable (and are in fact likely to be
completely identical).  As such, the clean cherry-pick case represents a
case when there is no information to be gained by keeping the extra
commit around.  All rebase types have always dropped these commits, and
no one to my knowledge has ever requested that we do otherwise.

For many of the become empty cases (and likely even most), we will also
be able to drop the commit without loss of information -- but this isn't
quite always the case.  Since these commits represent cases that were
not clean cherry-picks, there is no upstream commit message explaining
the same set of changes.  Projects with good commit message hygiene will
likely have the explanation from our commit message contained within or
spread among the relevant upstream commits, but not all projects run
that way.  As such, the commit message of the commit being rebased may
have reasoning that suggests additional changes that should be made to
adapt to the new base, or it may have information that someone wants to
add as a note to another commit, or perhaps someone even wants to create
an empty commit with the commit message as-is.

Junio commented on the "become-empty" types of commits as follows[1]:

    WRT a change that ends up being empty (as opposed to a change that
    is empty from the beginning), I'd think that the current behaviour
    is desireable one.  "am" based rebase is solely to transplant an
    existing history and want to stop much less than "interactive" one
    whose purpose is to polish a series before making it publishable,
    and asking for confirmation ("this has become empty--do you want to
    drop it?") is more appropriate from the workflow point of view.

[1] https://lore.kernel.org/git/xmqqfu1fswdh.fsf@gitster-ct.c.googlers.com/

I would simply add that his arguments for "am"-based rebases actually
apply to all non-explicitly-interactive rebases.  Also, since we are
stating that different cases should have different defaults, it may be
worth providing a flag to allow users to select which behavior they want
for these commits.

Introduce a new command line flag for selecting the desired behavior:
    --empty={drop,keep,ask}
with the definitions:
    drop: drop commits which become empty
    keep: keep commits which become empty
    ask:  provide the user a chance to interact and pick what to do with
          commits which become empty on a case-by-case basis

In line with Junio's suggestion, if the --empty flag is not specified,
pick defaults as follows:
    explicitly interactive: ask
    otherwise: drop

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

rebase (interactive-backend): make --keep-empty the default

Different rebase backends have different treatment for commits which
start empty (i.e. have no changes relative to their parent), and the
--keep-empty option was added at some point to allow adjusting behavior.
The handling of commits which start empty is actually quite similar to
commit b00bf1c9a8dd (git-rebase: make --allow-empty-message the default,
2018-06-27), which pointed out that the behavior for various backends is
often more happenstance than design.  The specific change made in that
commit is actually quite relevant as well and much of the logic there
directly applies here.

It makes a lot of sense in 'git commit' to error out on the creation of
empty commits, unless an override flag is provided.  However, once
someone determines that there is a rare case that merits using the
manual override to create such a commit, it is somewhere between
annoying and harmful to have to take extra steps to keep such
intentional commits around.  Granted, empty commits are quite rare,
which is why handling of them doesn't get considered much and folks tend
to defer to existing (accidental) behavior and assume there was a reason
for it, leading them to just add flags (--keep-empty in this case) that
allow them to override the bad defaults.  Fix the interactive backend so
that --keep-empty is the default, much like we did with
--allow-empty-message.  The am backend should also be fixed to have
--keep-empty semantics for commits that start empty, but that is not
included in this patch other than a testcase documenting the failure.

Note that there was one test in t3421 which appears to have been written
expecting --keep-empty to not be the default as correct behavior.  This
test was introduced in commit 00b8be5a4d38 ("add tests for rebasing of
empty commits", 2013-06-06), which was part of a series focusing on
rebase topology and which had an interesting original cover letter at
https://lore.kernel.org/git/1347949878-12578-1-git-send-email-martinvonz@gmail.com/
which noted
    Your input especially appreciated on whether you agree with the
    intent of the test cases.
and then went into a long example about how one of the many tests added
had several questions about whether it was correct.  As such, I believe
most the tests in that series were about testing rebase topology with as
many different flags as possible and were not trying to state in general
how those flags should behave otherwise.

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

prefix_path: show gitdir when arg is outside repo

When developing a script, it can be painful to understand why Git thinks
something is outside the current repo, if the current repo isn't what
the user thinks it is. Since this can be tricky to diagnose, especially
in cases like submodules or nested worktrees, let's give the user a hint
about which repository is offended about that path.

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

doc: move credential helper info into gitcredentials(7)

The details of how credential helpers can be called or implemented were
originally covered in Documentation/technical/. Those are topics that
end users might care about (and we even referenced them in the
credentials manpage), but those docs typically don't ship as part of the
end user documentation, making them less useful.

This situation got slightly worse recently in f3b9055624 (credential:
move doc to credential.h, 2019-11-17), where we moved them into the C
header file, making them even harder to find.

So let's move put this information into the gitcredentials(7)
documentation, which is meant to describe the overall concepts of our
credential handling. This was already pointing to the API docs for these
concepts, so we can just include it inline instead.

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

Sync with maint

The fifth batch for 2.26

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

Merge branch 'tb/commit-graph-object-dir'

The code to compute the commit-graph has been taught to use a more
robust way to tell if two object directories refer to the same
thing.

* tb/commit-graph-object-dir:
  commit-graph.h: use odb in 'load_commit_graph_one_fd_st'
  commit-graph.c: remove path normalization, comparison
  commit-graph.h: store object directory in 'struct commit_graph'
  commit-graph.h: store an odb in 'struct write_commit_graph_context'
  t5318: don't pass non-object directory to '--object-dir'

Merge branch 'jk/index-pack-dupfix'

The index-pack code now diagnoses a bad input packstream that
records the same object twice when it is used as delta base; the
code used to declare a software bug when encountering such an
input, but it is an input error.

* jk/index-pack-dupfix:
  index-pack: downgrade twice-resolved REF_DELTA to die()

Merge branch 'jk/alloc-cleanups'

Misc code clean-ups.

* jk/alloc-cleanups:
  tree-walk.c: break circular dependency with unpack-trees
  traverse_trees(): use stack array for name entries
  walker_fetch(): avoid raw array length computation
  normalize_path_copy(): document "dst" size expectations

Merge branch 'jh/notes-fanout-fix'

The code to automatically shrink the fan-out in the notes tree had
an off-by-one bug, which has been killed.

* jh/notes-fanout-fix:
  notes.c: fix off-by-one error when decreasing notes fanout
  t3305: check notes fanout more carefully and robustly

Merge branch 'pk/status-of-uncloned-submodule'

The way "git submodule status" reports an initialized but not yet
populated submodule has not been reimplemented correctly when a
part of the "git submodule" command was rewritten in C, which has
been corrected.

* pk/status-of-uncloned-submodule:
  t7400: testcase for submodule status on unregistered inner git repos
  submodule: fix status of initialized but not cloned submodules
  t7400: add a testcase for submodule status on empty dirs

Merge branch 'mt/use-passed-repo-more-in-funcs'

Some codepaths were given a repository instance as a parameter to
work in the repository, but passed the_repository instance to its
callees, which has been cleaned up (somewhat).

* mt/use-passed-repo-more-in-funcs:
  sha1-file: allow check_object_signature() to handle any repo
  sha1-file: pass git_hash_algo to hash_object_file()
  sha1-file: pass git_hash_algo to write_object_file_prepare()
  streaming: allow open_istream() to handle any repo
  pack-check: use given repo's hash_algo at verify_packfile()
  cache-tree: use given repo's hash_algo at verify_one()
  diff: make diff_populate_filespec() honor its repo argument

Merge branch 'jk/diff-honor-wserrhighlight-in-plumbing'

The diff-* plumbing family of subcommands now pay attention to the
diff.wsErrorHighlight configuration, which has been ignored before;
this allows "git add -p" to also show the whitespace problems to
the end user.

* jk/diff-honor-wserrhighlight-in-plumbing:
  diff: move diff.wsErrorHighlight to "basic" config

Merge branch 'ds/sparse-checkout-harden'

Some rough edges in the sparse-checkout feature, especially around
the cone mode, have been cleaned up.

* ds/sparse-checkout-harden:
  sparse-checkout: fix cone mode behavior mismatch
  sparse-checkout: improve docs around 'set' in cone mode
  sparse-checkout: escape all glob characters on write
  sparse-checkout: use C-style quotes in 'list' subcommand
  sparse-checkout: unquote C-style strings over --stdin
  sparse-checkout: write escaped patterns in cone mode
  sparse-checkout: properly match escaped characters
  sparse-checkout: warn on globs in cone patterns
  sparse-checkout: detect short patterns
  sparse-checkout: cone mode does not recognize "**"
  sparse-checkout: fix documentation typo for core.sparseCheckoutCone
  clone: fix --sparse option with URLs
  sparse-checkout: create leading directories
  t1091: improve here-docs
  t1091: use check_files to reduce boilerplate

Merge branch 'ld/p4-cleanup-processes'

p4 updates.

* ld/p4-cleanup-processes:
  git-p4: avoid leak of file handle when cloning
  git-p4: check for access to remote host earlier
  git-p4: cleanup better on error exit
  git-p4: create helper function importRevisions()
  git-p4: disable some pylint warnings, to get pylint output to something manageable
  git-p4: add P4CommandException to report errors talking to Perforce
  git-p4: make closeStreams() idempotent

Merge branch 'jt/connectivity-check-optim-in-partial-clone'

Unneeded connectivity check is now disabled in a partial clone when
fetching into it.

* jt/connectivity-check-optim-in-partial-clone:
  fetch: forgo full connectivity check if --filter
  connected: verify promisor-ness of partial clone

Merge branch 'jk/get-oid-error-message-i18n'

A low-level API function get_oid(), that accepts various ways to
name an object, used to issue end-user facing error messages
without l10n, which has been updated to be translatable.

* jk/get-oid-error-message-i18n:
  sha1-name: mark get_oid() error messages for translation
  t1506: drop space after redirection operator
  t1400: avoid "test" string comparisons

Merge branch 'ag/edit-todo-drop-check'

Allow the rebase.missingCommitsCheck configuration to kick in when
"rebase --edit-todo" and "rebase --continue" restarts the procedure.

* ag/edit-todo-drop-check:
  rebase-interactive: warn if commit is dropped with `rebase --edit-todo'
  sequencer: move check_todo_list_from_file() to rebase-interactive.c

Merge branch 'dl/test-must-fail-fixes-2'

Test updates.

* dl/test-must-fail-fixes-2:
  t4124: only mark git command with test_must_fail
  t3507: use test_path_is_missing()
  t3507: fix indentation
  t3504: do check for conflict marker after failed cherry-pick
  t3419: stop losing return code of git command
  t3415: increase granularity of test_auto_{fixup,squash}()
  t3415: stop losing return codes of git commands
  t3310: extract common notes_merge_files_gone()
  t3030: use test_path_is_missing()
  t2018: replace "sha" with "oid"
  t2018: don't lose return code of git commands
  t2018: teach do_checkout() to accept `!` arg
  t2018: be more discerning when checking for expected exit codes
  t2018: improve style of if-statement
  t2018: add space between function name and ()
  t2018: remove trailing space from test description

Merge branch 'ag/rebase-avoid-unneeded-checkout'

"git rebase -i" (and friends) used to unnecessarily check out the
tip of the branch to be rebased, which has been corrected.

* ag/rebase-avoid-unneeded-checkout:
  rebase -i: stop checking out the tip of the branch to rebase

Merge branch 'js/rebase-i-with-colliding-hash'

"git rebase -i" identifies existing commits in its todo file with
their abbreviated object name, which could become ambigous as it
goes to create new commits, and has a mechanism to avoid ambiguity
in the main part of its execution.  A few other cases however were
not covered by the protection against ambiguity, which has been
corrected.

* js/rebase-i-with-colliding-hash:
  rebase -i: also avoid SHA-1 collisions with missingCommitsCheck
  rebase -i: re-fix short SHA-1 collision
  parse_insn_line(): improve error message when parsing failed

Merge branch 'kw/fsmonitor-watchman-racefix'

A new version of fsmonitor-watchman hook has been introduced, to
avoid races.

* kw/fsmonitor-watchman-racefix:
  fsmonitor: update documentation for hook version and watchman hooks
  fsmonitor: add fsmonitor hook scripts for version 2
  fsmonitor: handle version 2 of the hooks that will use opaque token
  fsmonitor: change last update timestamp on the index_state to opaque token

Merge branch 'mt/threaded-grep-in-object-store'

Traditionally, we avoided threaded grep while searching in objects
(as opposed to files in the working tree) as accesses to the object
layer is not thread-safe.  This limitation is getting lifted.

* mt/threaded-grep-in-object-store:
  grep: use no. of cores as the default no. of threads
  grep: move driver pre-load out of critical section
  grep: re-enable threads in non-worktree case
  grep: protect packed_git [re-]initialization
  grep: allow submodule functions to run in parallel
  submodule-config: add skip_if_read option to repo_read_gitmodules()
  grep: replace grep_read_mutex by internal obj read lock
  object-store: allow threaded access to object reading
  replace-object: make replace operations thread-safe
  grep: fix racy calls in grep_objects()
  grep: fix race conditions at grep_submodule()
  grep: fix race conditions on userdiff calls

Merge branch 'jn/promote-proto2-to-default'

The transport protocol version 2 becomes the default one.

* jn/promote-proto2-to-default:
  fetch: default to protocol version 2
  protocol test: let protocol.version override GIT_TEST_PROTOCOL_VERSION
  test: request GIT_TEST_PROTOCOL_VERSION=0 when appropriate
  config doc: protocol.version is not experimental
  fetch test: use more robust test for filtered objects

Merge branch 'jk/packfile-reuse-cleanup'

The way "git pack-objects" reuses objects stored in existing pack
to generate its result has been improved.

* jk/packfile-reuse-cleanup:
  pack-bitmap: don't rely on bitmap_git->reuse_objects
  pack-objects: add checks for duplicate objects
  pack-objects: improve partial packfile reuse
  builtin/pack-objects: introduce obj_is_packed()
  pack-objects: introduce pack.allowPackReuse
  csum-file: introduce hashfile_total()
  pack-bitmap: simplify bitmap_has_oid_in_uninteresting()
  pack-bitmap: uninteresting oid can be outside bitmapped packfile
  pack-bitmap: introduce bitmap_walk_contains()
  ewah/bitmap: introduce bitmap_word_alloc()
  packfile: expose get_delta_base()
  builtin/pack-objects: report reused packfile objects

Merge branch 'hw/advice-add-nothing'

Two help messages given when "git add" notices the user gave it
nothing to add have been updated to use advise() API.

* hw/advice-add-nothing:
  add: change advice config variables used by the add API
  add: use advise function to display hints

Merge branch 'js/convert-typofix' into maint

Typofix.

* js/convert-typofix:
  convert: fix typo

Merge branch 'js/ci-squelch-doc-warning' into maint

Squelch unhelpful warning message during documentation build.

* js/ci-squelch-doc-warning:
  ci: ignore rubygems warning in the "Documentation" job

Merge branch 'jb/multi-pack-index-docfix' into maint

Doc fix.

* jb/multi-pack-index-docfix:
  pack-format: correct multi-pack-index description

Merge branch 'ma/diff-doc-clarify-regexp-example' into maint

Doc clarification.

* ma/diff-doc-clarify-regexp-example:
  diff-options.txt: avoid "regex" overload in example

Merge branch 'ms/doc-bundle-format' into maint

Technical details of the bundle format has been documented.
I think this is in a good enough shape.

* ms/doc-bundle-format:
  doc: describe Git bundle format

Merge branch 'es/submodule-fetch-message-fix' into maint

Error message fix.

* es/submodule-fetch-message-fix:
  submodule: add newline on invalid submodule error

Merge branch 'jb/parse-options-message-fix' into maint

Error message fix.

* jb/parse-options-message-fix:
  parse-options: lose an unnecessary space in an error message

Merge branch 'ma/filter-branch-doc-caret' into maint

Doc mark-up updates.

* ma/filter-branch-doc-caret:
  git-filter-branch.txt: wrap "maths" notation in backticks

Merge branch 'km/submodule-doc-use-sm-path' into maint

Docfix.

* km/submodule-doc-use-sm-path:
  submodule foreach: replace $path with $sm_path in example

Merge branch 'pb/do-not-recurse-grep-no-index' into maint

"git grep --no-index" should not get affected by the contents of
the .gitmodules file but when "--recurse-submodules" is given or
the "submodule.recurse" variable is set, it did.  Now these
settings are ignored in the "--no-index" mode.

* pb/do-not-recurse-grep-no-index:
  grep: ignore --recurse-submodules if --no-index is given