Make fsmonitor more robust to avoid the flakiness seen in t7527.

* jh/t7527-unflake-by-forcing-cookie:
  fsmonitor: fix race seen in t7527

Test fix.

* ab/t5314-avoid-losing-exit-status:
  t5314: check exit code of "git"

Test fix.

* ab/t7600-avoid-losing-exit-status-of-git:
  t7600: don't ignore "rev-parse" exit code in helper

Test fix.

* ab/t4023-avoid-losing-exit-status-of-diff:
  t4023: fix ignored exit codes of git

Stop using deprecated macOS API in fsmonitor.

* jh/fsmonitor-darwin-modernize:
  fsmonitor: eliminate call to deprecated FSEventStream function

Test fix.

* js/t3920-shell-and-or-fix:
  t3920: don't ignore errors of more than one command with `|| true`

Test fix.

* rs/t3920-crlf-eating-grep-fix:
  t3920: support CR-eating grep

Redefining system functions for a few functions did not follow our
usual "implement git_foo() and #define foo(args) git_foo(args)"
pattern, which has broken build for some folks.

* jk/avoid-redef-system-functions-2.30:
  git-compat-util: undefine system names before redeclaring them
  git-compat-util: avoid redefining system function names

The jk/avoid-redef-system-functions-2.30 topic pre-merged for more
recent codebase.

* jk/avoid-redef-system-functions:

The way the diff machinery prepares the options array for the
parse_options API has been refactored to avoid resource leaks.

* rs/diff-parseopts:
  diff: remove parseopts member from struct diff_options
  diff: use add_diff_options() in diff_opt_parse()
  diff: factor out add_diff_options()

Correct pthread API usage.

* sx/pthread-error-check-fix:
  maintenance: compare output of pthread functions for inequality with 0

Introduce a case insensitive mode to the Bash completion helpers.

* aw/complete-case-insensitive:
  completion: add case-insensitive match of pseudorefs
  completion: add optional ignore-case when matching refs

The advice message given by "git status" when it takes long time to
enumerate untracked paths has been updated.

* rr/status-untracked-advice:
  status: modernize git-status "slow untracked files" advice

Fix a pair of bugs in 'git branch'.

* rj/branch-copy-and-rename:
  branch: force-copy a branch to itself via @{-1} is a no-op

The code to auto-correct a misspelt subcommand unnecessarily called
into git_default_config() from the early config codepath, which was
a no-no.  This has bee corrected.

* sg/help-autocorrect-config-fix:
  help.c: fix autocorrect in work tree for bare repository

"git http-fetch" (which is rarely used) forgot to identify itself
in the trace2 output.

* jt/http-fetch-trace2-report-name:
  http-fetch: invoke trace2_cmd_name()

Code clean-up around unused function parameters.

* jk/unused-post-2.39:
  userdiff: mark unused parameter in internal callback
  list-objects-filter: mark unused parameters in virtual functions
  diff: mark unused parameters in callbacks
  xdiff: mark unused parameter in xdl_call_hunk_func()
  xdiff: drop unused parameter in def_ff()
  ws: drop unused parameter from ws_blank_line()
  list-objects: drop process_gitlink() function
  blob: drop unused parts of parse_blob_buffer()
  ls-refs: use repository parameter to iterate refs

Code clean-up.

* jk/server-supports-v2-cleanup:
  server_supports_v2(): use a separate function for die_on_error

Code clean-up.

* rs/am-parse-options-cleanup:
  am: don't pass strvec to apply_parse_options()

Code clean-up.

* rs/clear-commit-marks-cleanup:
  commit: skip already cleared parents in clear_commit_marks_1()

Code clean-up.

* rs/reflog-expiry-cleanup:
  reflog: clear leftovers in reflog_expiry_cleanup()

Code clean-up.

* rs/clarify-error-in-write-loose-object:
  object-file: inline write_buffer()

Clean-ups in error messages produced by "git for-each-ref" and friends.

* jk/ref-filter-error-reporting-fix:
  ref-filter: convert email atom parser to use err_bad_arg()
  ref-filter: truncate atom names in error messages
  ref-filter: factor out "unrecognized %(foo) arg" errors
  ref-filter: factor out "%(foo) does not take arguments" errors
  ref-filter: reject arguments to %(HEAD)

The output from "git diff --stat" on an unmerged path lost the
terminating LF in Git 2.39, which has been corrected.

* pg/diff-stat-unmerged-regression-fix:
  diff: fix regression with --stat and unmerged file

Code clean-up.

* sk/remove-duplicate-includes:
  git: remove duplicate includes

Use the SHA1DC implementation on macOS, just like other platforms,
by default.

* ab/darwin-default-to-sha1dc:
  Makefile: use sha1collisiondetection by default on OSX and Darwin

"git pull -v --recurse-submodules" attempted to pass "-v" down to
underlying "git submodule update", which did not understand the
request and barfed, which has been corrected.

* ss/pull-v-recurse-fix:
  submodule: accept -v for the update command

Just like "git var GIT_EDITOR" abstracts the complex logic to
choose which editor gets used behind it, "git var" now give support
to GIT_SEQUENCE_EDITOR.

* sa/git-var-sequence-editor:
  var: add GIT_SEQUENCE_EDITOR variable

When given a pattern that matches an empty string at the end of a
line, the code to parse the "git diff" line-ranges fell into an
infinite loop, which has been corrected.

* lk/line-range-parsing-fix:
  line-range: fix infinite loop bug with '$' regex

After "git pull" that is configured with pull.rebase=false
merge.ff=only fails due to our end having our own development, give
advice messages to get out of the "Not possible to fast-forward"
state.

* fc/advice-diverged-history:
  advice: add diverging advice for novices

…les' into next"

This reverts commit 390cd4f, reversing
changes made to 1c421f4.

…o next

Once we start running, we assumed that the list of alternate object
databases would never change.  Hook into the machinery used to
update the list of packfiles during runtime to update this list as
well.

* ds/reprepare-alternates-when-repreparing-packfiles:
  object-file: reprepare alternates when necessary

* ew/fetch-no-write-fetch-head-fix:
  fetch: pass --no-write-fetch-head to subprocesses

"git add -p" while the index is unmerged sometimes failed to parse
the diff output it internally produces and died, which has been
corrected.

* jk/add-p-unmerged-fix:
  add-patch: handle "* Unmerged path" lines

"git format-patch" honors the src/dst prefixes set to nonstandard
values with configuration variables like "diff.noprefix", causing
receiving end of the patch that expects the standard -p1 format to
break.  Teach "format-patch" to ignore end-user configuration and
always use the standard prefixes.

This is a backward compatibility breaking change.

* jk/format-patch-ignore-noprefix:
  format-patch: add format.noprefix option
  format-patch: do not respect diff.noprefix
  diff: add --default-prefix option
  t4013: add tests for diff prefix options
  diff: factor out src/dst prefix setup

"git format-patch" honors the src/dst prefixes set to nonstandard
values with configuration variables like "diff.noprefix", causing
receiving end of the patch that expects the standard -p1 format to
break.  Teach "format-patch" to ignore end-user configuration and
always use the standard prefixes.

This is a backward compatibility breaking change.

* jk/format-patch-ignore-noprefix:
  rebase: prefer --default-prefix to --{src,dst}-prefix for format-patch

Fix for a "ls-files --format="%(path)" that produced nonsense
output, which was a bug in 2.38.

* aj/ls-files-format-fix:
  ls-files: fix "--format" output of relative paths

"git receive-pack" that responds to "git push" requests failed to
clean a stale lockfile when killed in the middle, which has been
corrected.

* ps/receive-pack-unlock-before-die:
  receive-pack: fix stale packfile locks when dying

Code clean-up for test framework.

* fc/test-aggregation-clean-up:
  test: don't print aggregate-results command
  test: simplify counts aggregation

Previously, we punted on the question how to carry over amendments to
merge commits. Instead, we always performed new merges from scratch.

Such amendments to merge commits may very well be necessary, though,
e.g.  if one side of the history changed a function signature and the
other side added a caller.

In a discussion inspired by Johannes Sixt's "cherry-pick -m 1" idea,
Phillip Wood came up with the fundamental idea behind this commit.

The premise is that both "rebase" and "merge" try to reconcile diverging
changes. Both "rebase" and "merge" should result in identical trees
(after merge conflicts are resolved, if there were any).

A "merge" typically boils down to a "3-way" merge, with a "merge base"
and two "merge heads" that diverged from said merge base. Think e.g.
last week's master as the merge base, from where a developer branched
off a topic branch (the first merge head), and the current master as
second merge head.

A "rebase" is more complicated than a single "3-way merge": When
rebasing commits, they are "cherry-picked" one by one. That way, the
changes introduced by that commit are reconciled with the changes
introduced by the "rebase" so far: a "3-way merge" between HEAD and the
cherry-picked commit, with the latter's parent commit as merge base
(HEAD would be the rebased parent commit in the common case).

In the context of a cherry-pick, it is important to keep in mind that
the "diverging changes" are not reflected by commit history. For the
purpose of a 3-way merge, they don't have to be.

Now let's look again at the problem of "rebasing merge commits", i.e.
how to "cherry-pick a merge commit"? It is not as simple as a "3-way
merge" (a single one, that is) because we do not have a single merge
base from where sprung exactly two diverging changesets.

Just like when we cherry-pick a regular commit, in the case of a merge
commit we have diverging changes for *every* one of its parents. And
just like before, the original parent commit is the merge base, and the
rebased parent commit is a merge head. The other merge head is the
original merge commit itself.

By starting with the original merge commit and then performing these
3-way merges sequentially, one for every parent, we reconcile all
diverging changes. So we "rebased" the merge commit, including all of
its amendments.

This is the most logical generalization of the cherry-pick concept: if
we only have one parent, the strategy outlined above is identical to
Git's cherry-pick operation.

Side-note: While this description only talked about merge commits with
exactly two parent commits above, the principle still holds for merge
commits with more than two parent commits ("octopus merges").

That strategy requires an original merge commit, with a matching number
of parents, though, and therefore it would not make sense in general to
do this for every `merge` command in the todo list: what if there was no
original merge commit, or if the specified merge commit had a different
number of parents? It therefore cannot be the default mode for the
`merge` command, thus we introduce a new flag `-R` for that.

However, for existing merge commits, this strategy *is* valid and *does*
lead to the most intuitive results. Therefore, let's use it by default
when generating todo lists in `git rebase --rebase-merges`.

Original-idea-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Helped-by: Igor Djordjevic <igor.d.djordjevic@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

TODO: implement a test

Just like with `pick` commands, `merge` commands should also get a chance
to resolve already-recorded conflicts.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This commit adds a lengthy test case to t3430 that reflects some
challenging use cases for the --rebase-merges option.

In particular, it sets up a scenario which demonstrates that "evil merges"
happen in practice, and they are necessarily introducing those extra
changes that constitute an "evil merge".

It then sets up three "upstream" branches with competing changes that
are designed to conflict with the changes to rebase.

The purpose of this added test case is two-fold:

1. to document what we expect --rebase-merges to accomplish, and even more
   to document what we do *not* expect it to be able to do.

2. to explore what kinds of merge conflicts --rebase-merges can produce
   (spoiler alert: we can end up with some bad ones, with
   unintuitively-nested merge conflicts).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When rebasing a regular merge between two parent commits, we have that
problem that we have to perform *two* 3-way merges, because we want to
merge in the changes (like amendments, merge conflict resolutions, etc)
from the original merge commit, too.

When the first of these 3-way merges already had conflicts, then we run
the chance of ending up with nested conflicts in the second 3-way merge.

So let's see in that case whether we gain something by merging the
original merge commit with the other parent first, and if that resulted in
a clean merge, proceed to merge the first parent (in this case, we cannot
end up with nested merge conflicts).

This simplifies the realistic example of a nested merge conflict to a
non-nested merge conflict. Before:

	int hi(void) {
		printf("Hello, world!\n");
	}
	<<<<<<< intermediate merge
	<<<<<<<< HEAD
	/* main event loop */
	void event_loop(void) {
		/* TODO: place holder for now */
	========
	=======
	}
	>>>>>>> <HASH>... merge head #1
	/* caller */
	void caller(void) {
		hi();
	>>>>>>>> <HASH>... original merge
	}

With this patch, this becomes much simpler:

	int hi(void) {
		printf("Hello, world!\n");
	}
	/* main event loop */
	void event_loop(void) {
		/* TODO: place holder for now */
	}
	<<<<<<<< HEAD
	========
	/* caller */
	void caller(void) {
		hi();
	}
	>>>>>>>> <HASH>... intermediate merge

Note: this needs to be refactored and stuff and things. It may even be
necessary to dive deeper into the code and implement a "W merge" that
avoids the problem where (one part of) one file would benefit from merging
the second parent before the first, while another (part of the same) file
would benefit from the reverse order.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>