sha1-file: split OBJECT_INFO_FOR_PREFETCH

The OBJECT_INFO_FOR_PREFETCH bitflag was added to sha1-file.c in 0f4a4fb1
(sha1-file: support OBJECT_INFO_FOR_PREFETCH, 2019-03-29) and is used to
prevent the fetch_objects() method when enabled.

However, there is a problem with the current use. The definition of
OBJECT_INFO_FOR_PREFETCH is given by adding 32 to OBJECT_INFO_QUICK. This is
clearly stated above the definition (in a comment) that this is so
OBJECT_INFO_FOR_PREFETCH implies OBJECT_INFO_QUICK. The problem is that using
"flag & OBJECT_INFO_FOR_PREFETCH" means that OBJECT_INFO_QUICK also implies
OBJECT_INFO_FOR_PREFETCH.

Split out the single bit from OBJECT_INFO_FOR_PREFETCH into a new
OBJECT_INFO_SKIP_FETCH_OBJECT as the single bit and keep
OBJECT_INFO_FOR_PREFETCH as the union of two flags. This allows a clearer use
of flag checking while also keeping the implication of OBJECT_INFO_QUICK.

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

rebase docs: recommend `-r` over `-p`

The `--preserve-merges` option is now deprecated in favor of
`--rebase-merges`; Let's stop recommending the former.

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

docs: say that `--rebase=preserve` is deprecated

As of Git v2.22.0, the `--preserve-merges` backend of `git rebase` will
be officially deprecated in favor of the `--rebase-merges` backend.
Consequently, `git pull --rebase=preserve` will also be deprected. State
this explicitly.

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

tests: mark a couple more test cases as requiring `rebase -p`

The `--preserve-merges` option has been deprecated, and as a consequence
we started to mark test cases that require that option to be supported,
in preparation for removing that support eventually.

Since we marked those test cases, a couple more crept into the test
suite, and with this patch, we mark them, too.

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

request-pull: warn if the remote object is not the same as the local one

In some cases, git request-pull might be invoked with remote and
local objects that differ even though they point to the same commit.
For example, the remote object might be a lightweight tag
vs. an annotated tag on the local side; or the user might have
reworded the tag locally and forgotten to push it.

When this happens git-request-pull will not warn, because it only
checks that "git ls-remote" returns an SHA1 that matches the local
commit (known as $headrev in the script).  This patch makes
git-request-pull retrieve the tag object SHA1 while processing
the "git ls-remote" output, so that it can be matched against the
local object.

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

request-pull: quote regex metacharacters in local ref

The local part of the third argument of git-request-pull is used in
a regular expression without quoting it.  Use qr{} and \Q\E to ensure
that e.g. a period in a tag name does not match any character on the
remote side.

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

bundle verify: error out if called without an object database

The deal with bundles is: they really are thin packs, with very little
sugar on top. So we really need a repository (or more appropriately, an
object database) to work with, when asked to verify a bundle.

Let's error out with a useful error message if `git bundle verify` is
called without such an object database to work with.

Reported by Konstantin Ryabitsev.

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

mark_fsmonitor_valid(): mark the index as changed if needed

Without this bug fix, t7519's four "status doesn't detect unreported
modifications" test cases would fail occasionally (and, oddly enough,
*a lot* more frequently on Windows).

The reason is that these test cases intentionally use the side effect of
`git status` to re-write the index if any updates were detected: they
first clean the worktree, run `git status` to update the index as well
as show the output to the casual reader, then make the worktree dirty
again and expect no changes to reported if running with a mocked
fsmonitor hook.

The problem with this strategy was that the index was written during
said `git status` on the clean worktree for the *wrong* reason: not
because the index was marked as changed (it wasn't), but because the
recorded mtimes were racy with the index' own mtime.

As the mtime granularity on Windows is 100 nanoseconds (see e.g.
https://docs.microsoft.com/en-us/windows/desktop/SysInfo/file-times),
the mtimes of the files are often enough *not* racy with the index', so
that that `git status` call currently does not always update the index
(including the fsmonitor extension), causing the test case to fail.

The obvious fix: if we change *any* index entry's `CE_FSMONITOR_VALID`
flag, we should also mark the index as changed. That will cause the
index to be written upon `git status`, *including* an updated fsmonitor
extension.

Side note: Even though the reader might think that the t7519 issue
should be *much* more prevalent on Linux, given that the ext4 filesystem
(that seems to be used by every Linux distribution) stores mtimes in
nanosecond precision. However, ext4 uses `current_kernel_time()` (see
https://unix.stackexchange.com/questions/11599#comment762968_11599; it
is *amazingly* hard to find any proper source of information about such
ext4 questions) whose accuracy seems to depend on many factors but is
safely worse than the 100-nanosecond granularity of NTFS (again, it is
*horribly* hard to find anything remotely authoritative about this
question). So it seems that the racy index condition that hid the bug
fixed by this patch simply is a lot more likely on Linux than on
Windows. But not impossible ;-)

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

fill_stat_cache_info(): prepare for an fsmonitor fix

We will need to pass down the `struct index_state` to
`mark_fsmonitor_valid()` for an upcoming bug fix, and this here function
calls that there function, so we need to extend the signature of
`fill_stat_cache_info()` first.

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

merge: refuse --commit with --squash

Convert option_commit to tristate, representing the states of
'default/untouched', 'enabled-by-cli', 'disabled-by-cli'. With this in
place, check whether option_commit was enabled by cli when squashing a
merge. If so, error out, as this is not supported.

Previously, when --squash was supplied, 'option_commit' was silently
dropped. This could have been surprising to a user who tried to override
the no-commit behavior of squash using --commit explicitly.

Add a note to the --squash option for git-merge to clarify the
incompatibility, and add a test case to t7600-merge.sh

Cc: Junio C Hamano <redacted>
Cc: Rafael Ascensão <redacted>
Cc: Johannes Schindelin <redacted>
Signed-off-by: Vishal Verma <redacted>
Signed-off-by: Junio C Hamano <redacted>

server-info: do not list unlinked packs

Having non-existent packs in objects/info/packs causes
dumb HTTP clients to abort.

v2: use single loop with ALLOC_GROW as suggested by Jeff King

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

fetch-pack: send server options after command

Currently, if any server options are specified during a protocol v2
fetch, server options will be sent before "command=fetch". Write server
options to the request buffer in send_fetch_request() so that the
components of the request are sent in the correct order.

The protocol documentation states that the command must come first. The
Git server implementation in serve.c (see process_request() in that
file) tolerates any order of command and capability, which is perhaps
why we haven't noticed this. This was noticed when testing against a
JGit server implementation, which follows the documentation in this
regard.

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

grep: fail if call could output and name is null

grep_source(), which performs much of the work for Git's grep library,
allows passing an arbitrary struct grep_source which represents the text
which grep_source() should search to match a pattern in the provided
struct grep_opt. In most callers, the grep_source::name field is set to
an appropriate prefix to print before a colon when a result matches:

README:Git is an Open Source project covered by the GNU General

One caller, grep_buffer(), leaves the grep_source::name field set to
NULL because there isn't enough context to determine an appropriate name
for this kind of output line. In practice, this has been fine: the only
caller of grep_buffer() is "git log --grep", and that caller sets
grep_opt::status_only, which disables output and only checks whether a
match exists. But this is brittle: a future caller can call
grep_buffer() without grep_opt::status_only set, and as soon as it hits
a match, grep_source() will try to print the match and segfault:

(null):Git is an Open Source project covered by the GNU General

For example, a future caller might want to print all matching lines from
commits which match a regex.

Futureproof by diagnosing early a use of the API that could trigger that
condition, before we know whether the pattern matches:

BUG: grep.c:1783: grep call which could print a name requires
grep_source.name be non-NULL
Aborted

This way, the caller's author gets an indication of how to fix the issue
- by providing grep_source::name or setting grep_opt::status_only - and
they are warned of the potential for a segfault unconditionally, rather
than only if there is a match.

Noticed while adding such a call to a tutorial on revision walks.

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

git-p4: allow unshelving of branched files

When unshelving a changelist, git-p4 tries to work out the appropriate
parent commit in a given branch (default: HEAD).  To do this, it looks
at the state of any pre-existing files in the target Perforce branch,
omitting files added in the shelved changelist.  Currently, only files
added (or move targets) are classed as new.  However, files integrated
from other branches (i.e. a 'branch' action) also need to be considered
as added, for this purpose.

Signed-off-by: Simon Williams <redacted>
Acked-by: Luke Diamand <redacted>
Signed-off-by: Junio C Hamano <redacted>

trace2: fix tracing when NO_PTHREADS is defined

Teach trace2 TLS code to not rely on pthread_getspecific() when NO_PTHREADS
is defined.  Instead, always assume the context data of the main thread.

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

bisect--helper: verify HEAD could be parsed before continuing

In 06f5608c14e6 (bisect--helper: `bisect_start` shell function partially
in C, 2019-01-02), we introduced a call to `get_oid()` and did not check
whether it succeeded before using its output.

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

rebase: replace incorrect logical negation by correct bitwise one

In bff014dac7d9 (builtin rebase: support the `verbose` and `diffstat`
options, 2018-09-04), we added a line that wanted to remove the
`REBASE_DIFFSTAT` bit from the flags, but it used an incorrect negation.

Found by Coverity.

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

hash-object doc: stop mentioning git-cvsimport

Remove a reference to git-cvsimport in the intro. As can be seen from
the history of this command[1] it was originally intended for use with
git-cvsimport, but how it uses it (and that it uses it at all) is
irrelevant trivia at this point.

1. See 7672db20c2 ("[PATCH] Expose object ID computation functions.",
   2005-07-08) and 8b8840e046 ("[PATCH] cvsgit fixes: spaces in
   filenames and CVS server dialog woes", 2005-08-15).

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
Signed-off-by: Junio C Hamano <redacted>

revision: keep topo-walk free of unintersting commits

When updating the topo-order walk in b454241 (revision.c: generation-based
topo-order algorithm, 2018-11-01), the logic was a huge rewrite of the
walk logic. In that massive change, we accidentally included the
UNINTERESTING commits in expand_topo_walk(). This means that a simple
query like

    git rev-list --topo-order HEAD~1..HEAD

will expand the topo walk for all commits reachable from HEAD, and not
just one commit.

This change should speed up these cases, but there is still a need
for corrected commit-date for some A..B queries.

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

revision: use generation for A..B --topo-order queries

If a commit-graph exists with computed generation numbers, then a
'git rev-list --topo-order -n <N> <rev>' query will use those generation
numbers to reduce the number of commits walked before writing N commits.

One caveat put in b454241 (revision.c: generation-based topo-order
algorithm, 2018-11-01) was to not enable the new algorithm for queries
with a revision range "A..B". The logic was placed to walk from "A" and
mark those commits as uninteresting, but the performance was actually
worse than the existing logic in some cases.

The root cause of this performance degradation is that generation
numbers _increase_ the number of commits we walk relative to the
existing heuristic of walking by commit date. While generation numbers
actually guarantee that the algorithm is correct, the existing logic
is very rarely wrong and that added requirement is not worth the cost.

This motivates the planned "corrected commit date" to replace
generation numbers in a future version of Git.

The current change enables the logic to use whatever reachability
index is currently in the commit-graph (generation numbers or
corrected commit date).

The limited flag in struct rev_info forces a full walk of the
commit history (after discovering the A..B range). Previosuly, it
is enabled whenever we see an uninteresting commit. We prevent
enabling the parameter when we are planning to use the reachability
index for a topo-order.

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

am: fix --interactive HEAD tree resolution

In --interactive mode, "git am --resolved" will try to generate a patch
based on what is in the index, so that it can prompt "apply this
patch?". To do so it needs the tree of HEAD, which it tries to get with
get_oid_tree(). However, this doesn't yield a tree object; the "tree"
part just means "if you must disambiguate short oids, then prefer trees"
(and we do not need to disambiguate at all, since we are feeding a ref).

Instead, we must parse the oid as a commit (which should always be true
in a non-corrupt repository), and access its tree pointer manually.

This has been broken since the conversion to C in 7ff2683253
(builtin-am: implement -i/--interactive, 2015-08-04), but there was no
test coverage because of interactive-mode's insistence on having a tty.
That was lifted in the previous commit, so we can now add a test for
this case.

Note that before this patch, the test would result in a BUG() which
comes from 3506dc9445 (has_uncommitted_changes(): fall back to empty
tree, 2018-07-11). But before that, we'd have simply segfaulted (and in
fact this is the exact type of case the BUG() added there was trying to
catch!).

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

am: drop tty requirement for --interactive

We have required that the stdin of "am --interactive" be a tty since
a1451104ac (git-am: interactive should fail gracefully., 2005-10-12).
However, this isn't strictly necessary, and makes the tool harder to
test (and is unlike all of our other --interactive commands).

The goal of that commit was to make sure that somebody does not do:

  git am --interactive <mbox

and cause us to read commands from the mbox. But we can simply check
up front for this case and complain before entering the interactive
loop.

Technically this disallows:

  git am --interactive </dev/null

where our lack of patches means we would never prompt for anything, and
so the old code would not notice our lack of tty (and now we'd die
early). But since such a command is totally pointless, it's no loss.

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

am: read interactive input from stdin

In the conversion of git-am from shell script to C, we switched to using
git_prompt(). Unlike the original shell command "read reply", this
doesn't read from stdin at all, but rather from /dev/tty.

In most cases this distinction wouldn't matter. We require (as the shell
script did) that stdin is a tty, so they would generally be the same
thing. But one important exception is our test suite: even with
test_terminal, we cannot test "am --interactive" because it insists on
reading from /dev/tty, not the pseudo-tty we've set up in the test
script.

Fixing this clears the way to adding tests in a future patch.

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

am: simplify prompt response handling

We'll never see a NULL returned from git_prompt(); if it can't produce
any input for us (e.g., because the terminal got EOF) then it will just
die().

So there's no need for us to handle NULL here. And even if there was, it
doesn't make sense to continue; on a true terminal hangup we'd just loop
infinitely trying to get input that will never come.

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

progress: avoid empty line when breaking the progress line

Since commit 545dc345eb (progress: break too long progress bar lines,
2019-04-12) when splitting a too long progress line, sometimes it
looks as if a superfluous empty line were added between the title
line and the counters.

To make sure that the previously displayed progress line is completely
covered up when writing the new, shorter title line, we calculate how
many characters need to be overwritten with spaces.  Alas, this
calculation doesn't account for the newline character at the end of
the new title line, and resulted in printing one more space than
strictly necessary.  This extra space character doesn't matter, if the
length of the previous progress line was shorter than the width of the
terminal.  However, if the previous line matched the terminal width,
then this extra space made the new line longer, effectively adding
that empty line after the title line.

Fix this off-by-one to avoid that spurious empty line.

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

trace2: document the supported values of GIT_TRACE2* env variables

The descriptions of the GIT_TRACE2* environment variables link to the
technical docs for further details on the supported values.  However,
a link like this only really works if the docs are viewed in a browser
and the full documentation is available.  OTOH, in 'man git' there are
no links to conveniently click on, and distro-shipped git packages
tend to include only the man pages, while the technical docs and the
docs in html format are in a separate 'git-doc' package.

So let's describe the supported values to make the manpage more
self-contained, but still keep the references to the technical docs
because the details of the SID, and the JSON and perf output formats
are definitely beyond the scope of 'man git'.

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

trace2: rename environment variables to GIT_TRACE2*

For an environment variable that is supposed to be set by users, the
GIT_TR2* env vars are just too unclear, inconsistent, and ugly.

Most of the established GIT_* environment variables don't use
abbreviations, and in case of the few that do (GIT_DIR,
GIT_COMMON_DIR, GIT_DIFF_OPTS) it's quite obvious what the
abbreviations (DIR and OPTS) stand for.  But what does TR stand for?
Track, traditional, trailer, transaction, transfer, transformation,
transition, translation, transplant, transport, traversal, tree,
trigger, truncate, trust, or ...?!

The trace2 facility, as the '2' suffix in its name suggests, is
supposed to eventually supercede Git's original trace facility.  It's
reasonable to expect that the corresponding environment variables
follow suit, and after the original GIT_TRACE variables they are
called GIT_TRACE2; there is no such thing is 'GIT_TR'.

All trace2-specific config variables are, very sensibly, in the
'trace2' section, not in 'tr2'.

OTOH, we don't gain anything at all by omitting the last three
characters of "trace" from the names of these environment variables.

So let's rename all GIT_TR2* environment variables to GIT_TRACE2*,
before they make their way into a stable release.

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

upload-pack: strip namespace from symref data

Since 7171d8c15f (upload-pack: send symbolic ref information as
capability, 2013-09-17), we've sent cloning and fetching clients special
information about which branch HEAD is pointing to, so that they don't
have to guess based on matching up commit ids.

However, this feature has never worked properly with the GIT_NAMESPACE
feature.  Because upload-pack uses head_ref_namespaced(find_symref), we
do find and report on refs/namespaces/foo/HEAD instead of the actual
HEAD of the repo. This makes sense, since the branch pointed to by the
top-level HEAD may not be advertised at all. But we do two things wrong:

  1. We report the full name refs/namespaces/foo/HEAD, instead of just
     HEAD. Meaning no client is going to bother doing anything with that
     symref, since we're not otherwise advertising it.

  2. We report the symref destination using its full name (e.g.,
     refs/namespaces/foo/refs/heads/master). That's similarly useless to
     the client, who only saw "refs/heads/master" in the advertisement.

We should be stripping the namespace prefix off of both places (which
this patch fixes).

Likely nobody noticed because we tend to do the right thing anyway. Bug
(1) means that we said nothing about HEAD (just refs/namespace/foo/HEAD).
And so the client half of the code, from a45b5f0552 (connect: annotate
refs with their symref information in get_remote_head(), 2013-09-17),
does not annotate HEAD, and we use the fallback in guess_remote_head(),
matching refs by object id. Which is usually right. It only falls down
in ambiguous cases, like the one laid out in the included test.

This also means that we don't have to worry about breaking anybody who
was putting pre-stripped names into their namespace symrefs when we fix
bug (2). Because of bug (1), nobody would have been using the symref we
advertised in the first place (not to mention that those symrefs would
have appeared broken for any non-namespaced access).

Note that we have separate fixes here for the v0 and v2 protocols. The
symref advertisement moved in v2 to be a part of the ls-refs command.
This actually gets part (1) right, since the symref annotation
piggy-backs on the existing ref advertisement, which is properly
stripped. But it still needs a fix for part (2). The included tests
cover both protocols.

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

gitsubmodules: align html and nroff lists

There appears to be a bug in the toolchain generating manpages from
lettered lists. When a list is enumerated with letters, the resulting
nroff shows numbers instead. Mostly this is harmless, but in the case of
gitsubmodules, the paragraph following the list refers back to each
bullet by letter. As a result, reading this documentation via `man
gitsubmodules` is hard to parse - readers must infer that a bug exists
and a refers to 1, b refers to 2, and c refers to 3 in the list above.

The problem specifically was introduced in ad47194; previously rather
than generating numerated lists the bulleted area was entirely
monospaced in HTML and shown in plaintext in nroff.

The bug seems to exist in docbook-xml - I've reported it on May 1 via
the docbook-apps mail list - but for now it may make more sense to just
work around the issue.

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

l10n: es: 2.22.0 round 1

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

clone: add `--remote-submodules` flag

When using `git clone --recurse-submodules` there was previously no way to
pass a `--remote` switch to the implicit `git submodule update` command for
any use case where you want the submodules to be checked out on their
remote-tracking branch rather than with the SHA-1 recorded in the superproject.

This patch rectifies this situation. It actually passes `--no-fetch` to
`git submodule update` as well on the grounds they the submodule has only just
been cloned, so fetching from the remote again only serves to slow things down.

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

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

* 'master' of https://github.com/vnwildman/git:
  l10n: vi.po(4577t): Updated Vietnamese translation for v2.22.0 round 1

Git 2.22-rc1

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

Merge branch 'js/difftool-no-index'

The "--dir-diff" mode of "git difftool" is not useful in "--no-index"
mode; they are now explicitly marked as mutually incompatible.

* js/difftool-no-index:
  difftool --no-index: error out on --dir-diff (and don't crash)

Merge branch 'jk/get-oid-indexed-object-name'

The codepath to parse :<path> that obtains the object name for an
indexed object has been made more robust.

* jk/get-oid-indexed-object-name:
  get_oid: handle NULL repo->index

Merge branch 'jc/set-packet-header-signature-fix'

Code clean-up.

* jc/set-packet-header-signature-fix:
  pkt-line: drop 'const'-ness of a param to set_packet_header()

Merge branch 'cb/http-push-null-in-message-fix'

Code clean-up.

* cb/http-push-null-in-message-fix:
  http-push: prevent format overflow warning with gcc >= 9

Merge branch 'js/stash-in-c-use-builtin-doc'

Doc update.

* js/stash-in-c-use-builtin-doc:
  stash: document stash.useBuiltin

Merge branch 'tz/test-lib-check-working-jgit'

A prerequiste check in the test suite to see if a working jgit is
available was made more robust.

* tz/test-lib-check-working-jgit:
  test-lib: try harder to ensure a working jgit

Merge branch 'js/parseopt-unknown-cb-returns-an-enum'

Code clean-up.

* js/parseopt-unknown-cb-returns-an-enum:
  parse-options: adjust `parse_opt_unknown_cb()`s declared return type

Merge branch 'ab/sha1dc'

Update collision-detecting SHA-1 code to build properly on HP-UX.

* ab/sha1dc:
  sha1dc: update from upstream

Merge branch 'js/fsmonitor-refresh-after-discarding-index'

The fsmonitor interface got out of sync after the in-core index
file gets discarded, which has been corrected.

* js/fsmonitor-refresh-after-discarding-index:
  fsmonitor: force a refresh after the index was discarded
  fsmonitor: demonstrate that it is not refreshed after discard_index()

Merge branch 'js/rebase-i-label-shown-in-status-fix'

"git status" did not know that the "label" instruction in the
todo-list "rebase -i -r" uses should not be shown as a hex object
name.

* js/rebase-i-label-shown-in-status-fix:
  status: fix display of rebase -ir's `label` command

Merge branch 'es/check-non-portable-pre-5.10'

Developer support update.

* es/check-non-portable-pre-5.10:
  check-non-portable-shell: support Perl versions older than 5.10

Merge branch 'ds/trace2-document-env-vars'

Doc update.

* ds/trace2-document-env-vars:
  trace2: add variable description to git.txt

Merge branch 'cm/notes-comment-fix'

A stale in-code comment has been updated.

* cm/notes-comment-fix:
  notes: correct documentation of format_display_notes()

Merge branch 'tt/no-ipv6-fallback-for-winxp'

Code cleanup.

* tt/no-ipv6-fallback-for-winxp:
  mingw: remove obsolete IPv6-related code

Merge branch 'js/t5580-unc-alternate-test'

An additional test for MinGW

* js/t5580-unc-alternate-test:
  t5580: verify that alternates can be UNC paths

Merge branch 'ds/cvsexportcommit-force-text'

"git cvsexportcommit" running on msys did not expect cvsnt showed
"cvs status" output with CRLF line endings.

* ds/cvsexportcommit-force-text:
  cvsexportcommit: force crlf translation

Merge branch 'sg/ci-libsvn-perl'

To run tests for Git SVN, our scripts for CI used to install the
git-svn package (in the hope that it would bring in the right
dependencies).  This has been updated to install the more direct
dependency, namely, libsvn-perl.

* sg/ci-libsvn-perl:
  ci: install 'libsvn-perl' instead of 'git-svn'

Merge branch 'bl/t4253-exit-code-from-format-patch'

Avoid patterns to pipe output from a git command to feed another
command in tests.

* bl/t4253-exit-code-from-format-patch:
  t4253-am-keep-cr-dos: avoid using pipes

Merge branch 'ds/midx-too-many-packs'

The code to generate the multi-pack idx file was not prepared to
see too many packfiles and ran out of open file descriptor, which
has been corrected.

* ds/midx-too-many-packs:
  midx: add packs to packed_git linked list
  midx: pass a repository pointer

Merge branch 'en/unicode-in-refnames'

On a filesystem like HFS+, the names of the refs stored as filesystem
entities may become different from what the end-user expects, just
like files in the working tree get "renamed".  Work around the
mismatch by paying attention to the core.precomposeUnicode
configuration.

* en/unicode-in-refnames:
  Honor core.precomposeUnicode in more places

Merge branch 'dl/difftool-mergetool'

Update "git difftool" and "git mergetool" so that the combinations
of {diff,merge}.{tool,guitool} configuration variables serve as
fallback settings of each other in a sensible order.

* dl/difftool-mergetool:
  difftool: fallback on merge.guitool
  difftool: make --gui, --tool and --extcmd mutually exclusive
  mergetool: fallback to tool when guitool unavailable
  mergetool--lib: create gui_mode function
  mergetool: use get_merge_tool function
  t7610: add mergetool --gui tests
  t7610: unsuppress output

Merge branch 'mh/http-fread-api-fix'

A pair of private functions in http.c that had names similar to
fread/fwrite did not return the number of elements, which was found
to be confusing.

* mh/http-fread-api-fix:
  Make fread/fwrite-like functions in http.c more like fread/fwrite.

Merge branch 'js/t6500-use-windows-pid-on-mingw'

Future-proof a test against an update to MSYS2 runtime v3.x series.

* js/t6500-use-windows-pid-on-mingw:
  t6500(mingw): use the Windows PID of the shell

Merge branch 'jk/apache-lsan'

Allow tests that involve httpd to be run under leak sanitizer, just
like we can already do so under address sanitizer.

* jk/apache-lsan:
  t/lib-httpd: pass LSAN_OPTIONS through apache

Merge branch 'nd/parse-options-aliases'

Attempt to use an abbreviated option in "git clone --recurs" is
responded by a request to disambiguate between --recursive and
--recurse-submodules, which is bad because these two are synonyms.
The parse-options API has been extended to define such synonyms
more easily and not produce an unnecessary failure.

* nd/parse-options-aliases:
  parse-options: don't emit "ambiguous option" for aliases

Merge branch 'dl/branch-from-3dot-merge-base'

"git branch new A...B" and "git checkout -b new A...B" have been
taught that in their contexts, the notation A...B means "the merge
base between these two commits", just like "git checkout A...B"
detaches HEAD at that commit.

* dl/branch-from-3dot-merge-base:
  branch: make create_branch accept a merge base rev
  t2018: cleanup in current test

Merge branch 'js/commit-graph-parse-leakfix'

Leakfix.

* js/commit-graph-parse-leakfix:
  commit-graph: fix memory leak

Merge branch 'jk/cocci-batch'

Optionally "make coccicheck" can feed multiple source files to
spatch, gaining performance while spending more memory.

* jk/cocci-batch:
  coccicheck: make batch size of 0 mean "unlimited"
  coccicheck: optionally batch spatch invocations

Merge branch 'ab/perf-installed-fix'

Performance test framework has been broken and measured the version
of Git that happens to be on $PATH, not the specified one to
measure, for a while, which has been corrected.

* ab/perf-installed-fix:
  perf-lib.sh: forbid the use of GIT_TEST_INSTALLED
  perf tests: add "bindir" prefix to git tree test results
  perf-lib.sh: remove GIT_TEST_INSTALLED from perf-lib.sh
  perf-lib.sh: make "./run <revisions>" use the correct gits
  perf aggregate: remove GIT_TEST_INSTALLED from --codespeed
  perf README: correct docs for 3c8f12c96c regression

Merge branch 'id/windows-dep-aslr'

Allow DEP and ASLR for Windows build to for security hardening.

* id/windows-dep-aslr:
  mingw: enable DEP and ASLR
  mingw: do not let ld strip relocations

Merge branch 'ab/trace2-typofix'

Typofix.

* ab/trace2-typofix:
  trace2: fix up a missing "leave" entry point

Merge branch 'nd/submodule-helper-incomplete-line-fix'

Typofix.

* nd/submodule-helper-incomplete-line-fix:
  submodule--helper: add a missing \n

Merge branch 'cw/diff-highlight'

Portability fix for a diff-highlight tool (in contrib/).

* cw/diff-highlight:
  diff-highlight: use correct /dev/null for UNIX and Windows

Merge branch 'dl/warn-tagging-a-tag'

Typofix.

* dl/warn-tagging-a-tag:
  tag: fix typo in nested tagging hint

documentation: add anchors to MyFirstContribution

During the course of review for MyFirstContribution.txt, the suggestion
came up to include anchors to make it easier for veteran contributors to
link specific sections of this documents to newbies. To make life easier
for reviewers, add these anchors in their own commit. See review context
here: https://public-inbox.org/git/20190507195938.GD220818@google.com/

AsciiDoc does not support :sectanchors: and the anchors are not
discoverable, but they are referenceable. So a link to
"foo.com/MyFirstContribution.html#prerequisites" will still work if that
file was generated with AsciiDoc. The inclusion of :sectanchors: does
not create warnings or errors while compiling directly with `asciidoc -b
html5 Documentation/MyFirstContribution.txt` or while compiling with
`make doc`.

AsciiDoctor does support :sectanchors: and displays a paragraph link on
mouseover. When the anchor is included above or inline with a section
(as in this change), the link provided points to the custom ID contained
within [[]] instead of to an autogenerated ID. Practically speaking,
this means we have .../MyFirstContribution.html#summary instead of
.../MyFirstContribution.html#_summary. In addition to being prettier,
the custom IDs also enable anchor linking to work with
asciidoc-generated pages. This change compiles with no warnings using
`asciidoctor -b html5 Documentation/MyFirstContribution.txt`.

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

documentation: add tutorial for first contribution

This tutorial covers how to add a new command to Git and, in the
process, everything from cloning git/git to getting reviewed on the
mailing list. It's meant for new contributors to go through
interactively, learning the techniques generally used by the git/git
development community.

Reviewed-by: Johannes Schindelin <redacted>
Reviewed-by: Jonathan Tan <redacted>
Signed-off-by: Emily Shaffer <redacted>
Signed-off-by: Junio C Hamano <redacted>

diff: fix mistake in translatable strings

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

merge: add --quit

This allows to cancel the current merge without resetting worktree/index,
which is what --abort is for. Like other --quit(s), this is often used
when you forgot that you're in the middle of a merge and already
switched away, doing different things. By the time you've realized, you
can't even continue the merge anymore.

This also makes all in-progress commands, am, merge, rebase, revert and
cherry-pick, take all three --abort, --continue and --quit (bisect has a
different UI).

Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
Signed-off-by: Junio C Hamano <redacted>

userdiff: add Octave

Octave pattern is almost the same as matlab, except
that '%%%' and '##' can also be used to begin code sections,
in addition to '%%' that is understood by both. Octave
pattern is merged into Matlab pattern. Test cases for
the hunk header patterns of matlab and octave under
t/t4018 are added.

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

l10n: vi.po(4577t): Updated Vietnamese translation for v2.22.0 round 1

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

rebase -r: always reword merge -c

If a merge can be fast-forwarded then make sure that we still edit the
commit message if the user specifies -c. The implementation follows the
same pattern that is used for ordinary rewords that are fast-forwarded.

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

send-email: document --no-[to|cc|bcc]

These options added in f434c083a0 ("send-email: add --no-cc, --no-to,
and --no-bcc", 2010-03-07) were never documented.

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: fix broken transferEncoding tests

I fixed a bug that had broken the reading of sendmail.transferEncoding
in 3494dfd3ee ("send-email: do defaults -> config -> getopt in that
order", 2019-05-09), but the test I added in that commit did nothing
to assert the bug had been fixed.

That issue originates in 8d81408435 ("git-send-email: add
--transfer-encoding option", 2014-11-25) which first added the
"sendemail.transferencoding=8bit".

That test has never done anything meaningful. It tested that the
"--transfer-encoding=8bit" option would turn on the 8bit
Transfer-Encoding, but that was the default at the time (and now). As
checking out 8d81408435 and editing the test to remove that option
will reveal, supplying it never did anything.

So when I copied it thinking it would work in 3494dfd3ee I copied a
previously broken test, although I was making sure it did the right
thing via da-hoc debugger inspection, so the bug was fixed.

So fix the test I added in 3494dfd3ee, as well as the long-standing
test added in 8d81408435. To test if we're actually setting the
Transfer-Encoding let's set it to 7bit, not 8bit, as 7bit will error
out on "email-using-8bit".

This means that we can remove the "sendemail.transferencoding=7bit
fails on 8bit data" test, since it was redundant, we now have other
tests that assert that that'll fail.

While I'm at it convert "git config <key> <value>" in the test setup
to just "-c <key>=<value>" on the command-line. Then we don't need to
cleanup after these tests, and there's no sense in asserting where
config values come from in these tests, we can take that as a given.

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: remove cargo-culted multi-patch pattern in tests

Change test code added in f434c083a0 ("send-email: add --no-cc,
--no-to, and --no-bcc", 2010-03-07) which blindly copied a pattern
from an earlier test added in 32ae83194b ("add a test for
git-send-email for non-threaded mails", 2009-06-12) where the
"$patches" variable was supplied more than once.

As it turns out we didn't need more than one "$patches" for the test
added in 32ae83194b either. The only tests that actually needed this
sort of invocation were the tests added in 54aae5e1a0 ("t9001:
send-email interation with --in-reply-to and --chain-reply-to",
2010-10-19).

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
Signed-off-by: Junio C Hamano <redacted>

Makefile: remove the NO_R_TO_GCC_LINKER flag

Change our default CC_LD_DYNPATH invocation to something GCC likes
these days. Since the GCC 4.6 release unknown flags haven't been
passed through to ld(1). Thus our previous default of CC_LD_DYNPATH=-R
would cause an error on modern GCC unless NO_R_TO_GCC_LINKER was set.

This CC_LD_DYNPATH flag is really obscure, and I don't expect anyone
except those working on git development ever use this.

It's not needed to simply link to libraries like say libpcre,
but *only* for those cases where we're linking to such a library not
present in the OS's library directories. See e.g. ldconfig(8) on Linux
for more details.

I use this to compile my git with a LIBPCREDIR=$HOME/g/pcre2/inst as
I'm building that from source, but someone maintaining an OS package
is almost certainly not going to use this. They're just going to set
USE_LIBPCRE=YesPlease after installing the libpcre dependency,
which'll point to OS libraries which ld(1) will find without the help
of CC_LD_DYNPATH.

Another thing that helps mitigate any potential breakage is that we
detect the right type of invocation in configure.ac, which e.g. HP/UX
uses[1], as does IBM's AIX package[2]. From what I can tell both AIX
and Solaris packagers are building git with GCC, so I'm not adding a
corresponding config.mak.uname default to cater to their OS-native
linkers.

Now for an overview of past development in this area:

Our use of "-R" dates back to 455a7f3275 ("More portability.",
2005-09-30). Soon after that in bbfc63dd78 ("gcc does not necessarily
pass runtime libpath with -R", 2006-12-27) the NO_R_TO_GCC flag was
added, allowing optional use of "-Wl,-rpath=".

Then in f5b904db6b ("Makefile: Allow CC_LD_DYNPATH to be overriden",
2008-08-16) the ability to override this flag to something else
entirely was added, as some linkers use neither "-Wl,-rpath," nor
"-R".

From what I can tell we should, with the benefit of hindsight, have
made this change back in 2006. GCC & ld supported this type of
invocation back then, or since at least binutils-gdb.git's[3]
a1ad915dc4 ("[...]Add support for -rpath[...]", 1994-07-20).

Further reading and prior art can be found at [4][5][6][7]. Making a
plain "-R" an error seems from reading those reports to have been
introduced in GCC 4.6 released on March 25, 2011[8], but I couldn't
confirm this with absolute certainty, its release notes are ambiguous
on the subject, and I couldn't be bothered to try to build & bisect it
against GCC 4.5.

1. https://public-inbox.org/git/20190516093412.14795-1-avarab@gmail.com/
2. https://www.ibm.com/developerworks/aix/library/aix-toolbox/alpha.html
3. git://sourceware.org/git/binutils-gdb.git
4. https://github.com/tsuna/boost.m4/issues/15
5. https://bugzilla.gnome.org/show_bug.cgi?id=641416
6. https://stackoverflow.com/questions/12629042/g-4-6-real-error-unrecognized-option-r
7. https://curl.haxx.se/mail/archive-2014-11/0005.html
8. https://gcc.gnu.org/gcc-4.6/changes.html

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
Signed-off-by: Junio C Hamano <redacted>

l10n: fr.po v2.22.0.rnd1

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

userdiff: add built-in pattern for rust

This adds xfuncname and word_regex patterns for Rust, a quite
popular programming language. It also includes test cases for the
xfuncname regex (t4018) and updated documentation.

The word_regex pattern finds identifiers, integers, floats and
operators, according to the Rust Reference Book.

Cc: Johannes Sixt <redacted>
Signed-off-by: Marc-André Lureau <redacted>
Signed-off-by: Junio C Hamano <redacted>

format-patch: teach format.notes config option

In git-format-patch, notes can be appended with the `--notes` option.
However, this must be specified by the user on an
invocation-by-invocation basis. If a user is not careful, it's possible
that they may forget to include it and generate a patch series without
notes.

Teach git-format-patch the `format.notes` config option. Its value is a
notes ref that will be automatically appended. The special value of
"standard" can be used to specify the standard notes. This option is
overridable with the `--no-notes` option in case a user wishes not to
append notes.

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

Use xmmap_gently instead of xmmap in use_pack

use_pack has its own error message on mmap error, but it can't be
reached when using xmmap, which dies with its own error.

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

dup() the input fd for fast-import used for remote helpers

When a remote helper exposes the "import" capability, stdout of the
helper is sent to stdin of a new fast-import process. This is done by
setting the corresponding child_process's in field to the value of the
out field of the helper child_process.

The child_process API is defined to close the file descriptors it's
given when calling start_command. This means when start_command is
called for the fast-import process, its input fd (the output fd of the
helper), is closed.

But when the transport helper is later destroyed, in disconnect_helper,
its input and output are closed, which means close() is called with
an invalid fd (since it was already closed as per above). Or worse, with
a valid fd owned by something else (since fd numbers can be reused).

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

pkt-line: drop 'const'-ness of a param to set_packet_header()

The function's definition has a paramter of type "int" qualified as
"const".  The fact that the incoming parameter is used as read-only
in the fuction is an implementation detail that the callers should
not have to be told in the prototype declaring it (and "const" there
has no effect, as C passes parameters by value).

The prototype defined for the function in pkt-line.h lacked the
matching "const" for this reason, but apparently some compilers
(e.g. MS Visual C 2017) complain about the parameter type mismatch.

Let's squelch it by removing the "const" that is pointless in the
definition of a small and trivial function like this, which would
not help optimizing compilers nor reading humans that much.

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

blame: optionally track line fingerprints during fill_blame_origin()

fill_blame_origin() is a convenient place to store data that we will use
throughout the lifetime of a blame_origin.  Some heuristics for
ignoring commits during a blame session can make use of this storage.
In particular, we will calculate a fingerprint for each line of a file
for blame_origins involved in an ignored commit.

In this commit, we only calculate the line_starts, reusing the existing
code from the scoreboard's line_starts.  In an upcoming commit, we will
actually compute the fingerprints.

This feature will be used when we attempt to pass blame entries to
parents when we "ignore" a commit.  Most uses of fill_blame_origin()
will not require this feature, hence the flag parameter.  Multiple calls
to fill_blame_origin() are idempotent, and any of them can request the
creation of the fingerprints structure.

Suggested-by: Michael Platings <redacted>
Signed-off-by: Barret Rhoden <redacted>
Signed-off-by: Junio C Hamano <redacted>

blame: add config options for the output of ignored or unblamable lines

When ignoring commits, the commit that is blamed might not be
responsible for the change, due to the inaccuracy of our heuristic.
Users might want to know when a particular line has a potentially
inaccurate blame.

Furthermore, guess_line_blames() may fail to find any parent commit for
a given line touched by an ignored commit.  Those 'unblamable' lines
remain blamed on an ignored commit.  Users might want to know if a line
is unblamable so that they do not spend time investigating a commit they
know is uninteresting.

This patch adds two config options to mark these two types of lines in
the output of blame.

The first option can identify ignored lines by specifying
blame.markIgnoredLines.  When this option is set, each blame line that
was blamed on a commit other than the ignored commit is marked with a
'?'.

For example:
278b6158d6fdb (Barret Rhoden  2016-04-11 13:57:54 -0400 26)
appears as:
?278b6158d6fd (Barret Rhoden  2016-04-11 13:57:54 -0400 26)

where the '?' is placed before the commit, and the hash has one fewer
characters.

Sometimes we are unable to even guess at what ancestor commit touched a
line.  These lines are 'unblamable.'  The second option,
blame.markUnblamableLines, will mark the line with '*'.

For example, say we ignore e5e8d36d04cbe, yet we are unable to blame
this line on another commit:
e5e8d36d04cbe (Barret Rhoden  2016-04-11 13:57:54 -0400 26)
appears as:
*e5e8d36d04cb (Barret Rhoden  2016-04-11 13:57:54 -0400 26)

When these config options are used together, every line touched by an
ignored commit will be marked with either a '?' or a '*'.

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

blame: add the ability to ignore commits and their changes

Commits that make formatting changes or function renames are often not
interesting when blaming a file.  A user may deem such a commit as 'not
interesting' and want to ignore and its changes it when assigning blame.

For example, say a file has the following git history / rev-list:

---O---A---X---B---C---D---Y---E---F

Commits X and Y both touch a particular line, and the other commits do
not:

X: "Take a third parameter"
-MyFunc(1, 2);
+MyFunc(1, 2, 3);

Y: "Remove camelcase"
-MyFunc(1, 2, 3);
+my_func(1, 2, 3);

git-blame will blame Y for the change.  I'd like to be able to ignore Y:
both the existence of the commit as well as any changes it made.  This
differs from -S rev-list, which specifies the list of commits to
process for the blame.  We would still process Y, but just don't let the
blame 'stick.'

This patch adds the ability for users to ignore a revision with
--ignore-rev=rev, which may be repeated.  They can specify a set of
files of full object names of revs, e.g. SHA-1 hashes, one per line.  A
single file may be specified with the blame.ignoreRevFile config option
or with --ignore-rev-file=file.  Both the config option and the command
line option may be repeated multiple times.  An empty file name "" will
clear the list of revs from previously processed files.  Config options
are processed before command line options.

For a typical use case, projects will maintain the file containing
revisions for commits that perform mass reformatting, and their users
have the option to ignore all of the commits in that file.

Additionally, a user can use the --ignore-rev option for one-off
investigation.  To go back to the example above, X was a substantive
change to the function, but not the change the user is interested in.
The user inspected X, but wanted to find the previous change to that
line - perhaps a commit that introduced that function call.

To make this work, we can't simply remove all ignored commits from the
rev-list.  We need to diff the changes introduced by Y so that we can
ignore them.  We let the blames get passed to Y, just like when
processing normally.  When Y is the target, we make sure that Y does not
*keep* any blames.  Any changes that Y is responsible for get passed to
its parent.  Note we make one pass through all of the scapegoats
(parents) to attempt to pass blame normally; we don't know if we *need*
to ignore the commit until we've checked all of the parents.

The blame_entry will get passed up the tree until we find a commit that
has a diff chunk that affects those lines.

One issue is that the ignored commit *did* make some change, and there is
no general solution to finding the line in the parent commit that
corresponds to a given line in the ignored commit.  That makes it hard
to attribute a particular line within an ignored commit's diff
correctly.

For example, the parent of an ignored commit has this, say at line 11:

commit-a 11) #include "a.h"
commit-b 12) #include "b.h"

Commit X, which we will ignore, swaps these lines:

commit-X 11) #include "b.h"
commit-X 12) #include "a.h"

We can pass that blame entry to the parent, but line 11 will be
attributed to commit A, even though "include b.h" came from commit B.
The blame mechanism will be looking at the parent's view of the file at
line number 11.

ignore_blame_entry() is set up to allow alternative algorithms for
guessing per-line blames.  Any line that is not attributed to the parent
will continue to be blamed on the ignored commit as if that commit was
not ignored.  Upcoming patches have the ability to detect these lines
and mark them in the blame output.

The existing algorithm is simple: blame each line on the corresponding
line in the parent's diff chunk.  Any lines beyond that stay with the
target.

For example, the parent of an ignored commit has this, say at line 11:

commit-a 11) void new_func_1(void *x, void *y);
commit-b 12) void new_func_2(void *x, void *y);
commit-c 13) some_line_c
commit-d 14) some_line_d

After a commit 'X', we have:

commit-X 11) void new_func_1(void *x,
commit-X 12)                 void *y);
commit-X 13) void new_func_2(void *x,
commit-X 14)                 void *y);
commit-c 15) some_line_c
commit-d 16) some_line_d

Commit X nets two additionally lines: 13 and 14.  The current
guess_line_blames() algorithm will not attribute these to the parent,
whose diff chunk is only two lines - not four.

When we ignore with the current algorithm, we get:

commit-a 11) void new_func_1(void *x,
commit-b 12)                 void *y);
commit-X 13) void new_func_2(void *x,
commit-X 14)                 void *y);
commit-c 15) some_line_c
commit-d 16) some_line_d

Note that line 12 was blamed on B, though B was the commit for
new_func_2(), not new_func_1().  Even when guess_line_blames() finds a
line in the parent, it may still be incorrect.

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

blame: use a helper function in blame_chunk()

The same code for splitting a blame_entry at a particular line was used
twice in blame_chunk(), and I'll use the helper again in an upcoming
patch.

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

Move oidset_parse_file() to oidset.c

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

fsck: rename and touch up init_skiplist()

init_skiplist() took a file consisting of SHA-1s and comments and added
the objects to an oidset.  This functionality is useful for other
commands and will be moved to oidset.c in a future commit.

In preparation for that move, this commit renames it to
oidset_parse_file() to reflect its more generic usage and cleans up a
few of the names.

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

Doc: git.txt: remove backticks from link and add git-scm.com/docs

While checking the html formatted git(1) manual page, it was noted
that the link to https://git.github.io/htmldocs/git.html was formatted
as code. Remove the backticks.

While at it, add the https://git-scm.com/docs link which one reviewer
noted had linkable section headings.

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

git.c: show usage for accessing the git(1) help page

It is not immediately obvious how to use the `git help` system to show
the git(1) page, with its overview and its background and coordinating
material, such as environment variables.

Let's simply list it as the last few words of the last usage line.

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

test-lib: try harder to ensure a working jgit

The JGIT prereq uses `type jgit` to determine whether jgit is present.
While this is usually sufficient, it won't help if the jgit found is
badly broken.  This wastes time running tests which fail due to no fault
of our own.

Use `jgit --version` instead, to guard against cases where jgit is
present on the system, but will fail to run, e.g. because of some JRE
issue, or missing Java dependencies.  Checking that it gets far enough
to process the '--version' argument isn't perfect, but seems to be good
enough in practice.  It's also consistent with how we detect some other
dependencies, see e.g. the CURL and UNZIP prerequisites.

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

worktree add: be tolerant of corrupt worktrees

find_worktree() can die() unexpectedly because it uses real_path()
instead of the gentler version. When it's used in 'git worktree add' [1]
and there's a bad worktree, this die() could prevent people from adding
new worktrees.

The "bad" condition to trigger this is when a parent of the worktree's
location is deleted. Then real_path() will complain.

Use the other version so that bad worktrees won't affect 'worktree
add'. The bad ones will eventually be pruned, we just have to tolerate
them for a bit.

[1] added in cb56f55c16 (worktree: disallow adding same path multiple
    times, 2018-08-28), or since v2.20.0. Though the real bug in
    find_worktree() is much older.

Reported-by: Shaheed Haque <redacted>
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
Signed-off-by: Junio C Hamano <redacted>

get_oid: handle NULL repo->index

When get_oid() and its helpers see an index name like ":.gitmodules",
they try to load the index on demand, like:

  if (repo->index->cache)
repo_read_index(repo);

However, that misses the case when "repo->index" itself is NULL; we'll
segfault in the conditional.

This never happens with the_repository; there we always point its index
field to &the_index. But a submodule repository may have a NULL index
field until somebody calls repo_read_index().

This bug is triggered by t7411, but it was hard to notice because it's
in an expect_failure block. That test was added by 2b1257e463 (t/helper:
add test-submodule-nested-repo-config, 2018-10-25). Back then we had no
easy way to access the .gitmodules blob of a submodule repo, so we
expected (and got) an error message to that effect. Later, d9b8b8f896
(submodule-config.c: use repo_get_oid for reading .gitmodules,
2019-04-16) started looking in the correct repo, which is when we
started triggering the segfault.

With this fix, the test starts passing (once we clean it up as its
comment instructs).

Note that as far as I know, this bug could not be triggered outside of
the test suite. It requires resolving an index name in a submodule, and
all of the code paths (aside from test-tool) which do that either load
the index themselves, or always pass the_repository.

Ultimately it comes from 3a7a698e93 (sha1-name.c: remove implicit
dependency on the_index, 2019-01-12), which replaced a check of
"the_index.cache" with "repo->index->cache". So even if there is another
way to trigger it, it wouldn't affect any versions before then.

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

update-server-info: avoid needless overwrites

Do not change the existing info/refs and objects/info/packs
files if they match the existing content on the filesystem.
This is intended to preserve mtime and make it easier for dumb
HTTP pollers to rely on the If-Modified-Since header.

Combined with stdio and kernel buffering; the kernel should be
able to avoid block layer writes and reduce wear for small files.

As a result, the --force option is no longer needed.  So stop
documenting it, but let it remain for compatibility (and
debugging, if necessary).

v3: perform incremental comparison while generating to avoid
    OOM with giant files.  Remove documentation for --force.

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

worktree add: sanitize worktree names

Worktree names are based on $(basename $GIT_WORK_TREE). They aren't
significant until 3a3b9d8cde (refs: new ref types to make per-worktree
refs visible to all worktrees - 2018-10-21), where worktree name could
be part of a refname and must follow refname rules.

Update 'worktree add' code to remove special characters to follow
these rules. In the future the user will be able to specify the
worktree name by themselves if they're not happy with this dumb
character substitution.

Reported-by: Konstantin Kharlamov <redacted>
Helped-by: Jeff King <redacted>
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
Signed-off-by: Junio C Hamano <redacted>

http-push: prevent format overflow warning with gcc >= 9

In function 'finish_request',
    inlined from 'process_response' at http-push.c:248:2:
http-push.c:587:4: warning: '%s' directive argument is null [-Wformat-overflow=]
  587 |    fprintf(stderr, "Unable to get pack file %s\n%s",
      |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  588 |     request->url, curl_errorstr);
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

request->url is needed for the error message if there was a failure
during fetch but was being cleared unnecessarily earlier.

note that the leak is prevented by calling release_request unconditionally
at the end.

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

index-pack: prefetch missing REF_DELTA bases

When fetching, the client sends "have" commit IDs indicating that the
server does not need to send any object referenced by those commits,
reducing network I/O. When the client is a partial clone, the client
still sends "have"s in this way, even if it does not have every object
referenced by a commit it sent as "have".

If a server omits such an object, it is fine: the client could lazily
fetch that object before this fetch, and it can still do so after.

The issue is when the server sends a thin pack containing an object that
is a REF_DELTA against such a missing object: index-pack fails to fix
the thin pack. When support for lazily fetching missing objects was
added in 8b4c0103a9 ("sha1_file: support lazily fetching missing
objects", 2017-12-08), support in index-pack was turned off in the
belief that it accesses the repo only to do hash collision checks.
However, this is not true: it also needs to access the repo to resolve
REF_DELTA bases.

Support for lazy fetching should still generally be turned off in
index-pack because it is used as part of the lazy fetching process
itself (if not, infinite loops may occur), but we do need to fetch the
REF_DELTA bases. (When fetching REF_DELTA bases, it is unlikely that
those are REF_DELTA themselves, because we do not send "have" when
making such fetches.)

To resolve this, prefetch all missing REF_DELTA bases before attempting
to resolve them. This both ensures that all bases are attempted to be
fetched, and ensures that we make only one request per index-pack
invocation, and not one request per missing object.

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

t5616: refactor packfile replacement

A subsequent patch will perform the same packfile replacement that is
already done twice, so refactor it into its own function. Also, the same
subsequent patch will use, in another way, part of the packfile
replacement functionality, so extract those out too.

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