Merge branch 'ln/userdiff-elixir'

The patterns to detect function boundary for Elixir language has
been added.

* ln/userdiff-elixir:
  userdiff: add Elixir to supported userdiff languages

Merge branch 'py/shortlog-list-options-for-log'

Documentation pages for "git shortlog" now lists commit limiting
options explicitly.

* py/shortlog-list-options-for-log:
  git-shortlog.txt: include commit limiting options

Merge branch 'en/doc-typofix'

Docfix.

* en/doc-typofix:
  Fix spelling errors in no-longer-updated-from-upstream modules
  multimail: fix a few simple spelling errors
  sha1dc: fix trivial comment spelling error
  Fix spelling errors in test commands
  Fix spelling errors in messages shown to users
  Fix spelling errors in names of tests
  Fix spelling errors in comments of testcases
  Fix spelling errors in code comments
  Fix spelling errors in documentation outside of Documentation/
  Documentation: fix a bunch of typos, both old and new

Merge branch 'ns/test-desc-typofix'

Typofix.

* ns/test-desc-typofix:
  t: fix typo in test descriptions

Merge branch 'en/t6024-style'

Test updates.

* en/t6024-style:
  t6024: modernize style

Merge branch 'en/misc-doc-fixes'

Misc doc fixes.

* en/misc-doc-fixes:
  name-hash.c: remove duplicate word in comment
  hashmap: fix documentation misuses of -> versus .
  git-filter-branch.txt: correct argument name typo

Merge branch 'js/fetch-multi-lockfix'

Fetching from multiple remotes into the same repository in parallel
had a bad interaction with the recent change to (optionally) update
the commit-graph after a fetch job finishes, as these parallel
fetches compete with each other.  Which has been corrected.

* js/fetch-multi-lockfix:
  fetch: avoid locking issues between fetch.jobs/fetch.writeCommitGraph
  fetch: add the command-line option `--write-commit-graph`

Merge branch 'rs/trace2-dots'

Code cleanup.

* rs/trace2-dots:
  trace2: add dots directly to strbuf in perf_fmt_prepare()

Merge branch 'kw/fsmonitor-watchman-fix'

The watchman integration for fsmonitor was racy, which has been
corrected to be more conservative.

* kw/fsmonitor-watchman-fix:
  fsmonitor: fix watchman integration

Merge branch 'cb/curl-use-xmalloc'

HTTP transport had possible allocator/deallocator mismatch, which
has been corrected.

* cb/curl-use-xmalloc:
  remote-curl: unbreak http.extraHeader with custom allocators

Merge branch 'rt/fetch-message-fix'

A small message update.

* rt/fetch-message-fix:
  fetch.c: fix typo in a warning message

Merge branch 'es/myfirstcontrib-updates'

Doc updates.

* es/myfirstcontrib-updates:
  myfirstcontrib: hint to find gitgitgadget allower
  myfirstcontrib: add dependency installation step
  myfirstcontrib: add 'psuh' to command-list.txt

Merge branch 'hw/config-doc-in-header'

Follow recent push to move API docs from Documentation/ to header
files and update config.h

* hw/config-doc-in-header:
  config: move documentation to config.h

Merge branch 'dl/doc-diff-no-index-implies-exit-code'

Doc update.

* dl/doc-diff-no-index-implies-exit-code:
  git-diff.txt: document return code of `--no-index`

Merge branch 'js/vreportf-wo-buffering'

Messages from die() etc. can be mixed up from multiple processes
without even line buffering on Windows, which has been worked
around.

* js/vreportf-wo-buffering:
  vreportf(): avoid relying on stdio buffering

Merge branch 'pb/no-recursive-reset-hard-in-worktree-add'

"git worktree add" internally calls "reset --hard" that should not
descend into submodules, even when submodule.recurse configuration
is set, but it was affected.  This has been corrected.

* pb/no-recursive-reset-hard-in-worktree-add:
  worktree: teach "add" to ignore submodule.recurse config

Merge branch 'pb/help-list-gitsubmodules-among-guides'

Help update.

* pb/help-list-gitsubmodules-among-guides:
  help: add gitsubmodules to the list of guides

Merge branch 'sg/blame-indent-heuristics-is-now-the-default'

Message update.

* sg/blame-indent-heuristics-is-now-the-default:
  builtin/blame.c: remove '--indent-heuristic' from usage string

Merge branch 'mr/clone-dir-exists-to-path-exists'

Code cleanup.

* mr/clone-dir-exists-to-path-exists:
  clone: rename static function `dir_exists()`.

Merge branch 'ma/bisect-doc-sample-update'

"git merge --no-commit" needs "--no-ff" if you do not want to move
HEAD, which has been corrected in the manual page for "git bisect".

* ma/bisect-doc-sample-update:
  Documentation/git-bisect.txt: add --no-ff to merge command

Merge branch 'js/git-path-head-dot-lock-fix'

"git rev-parse --git-path HEAD.lock" did not give the right path
when run in a secondary worktree.

* js/git-path-head-dot-lock-fix:
  git_path(): handle `.lock` files correctly
  t1400: wrap setup code in test case

Merge branch 'jc/log-graph-simplify'

The implementation of "git log --graph" got refactored and then its
output got simplified.

* jc/log-graph-simplify:
  t4215: use helper function to check output
  graph: fix coloring of octopus dashes
  graph: flatten edges that fuse with their right neighbor
  graph: smooth appearance of collapsing edges on commit lines
  graph: rename `new_mapping` to `old_mapping`
  graph: commit and post-merge lines for left-skewed merges
  graph: tidy up display of left-skewed merges
  graph: example of graph output that can be simplified
  graph: extract logic for moving to GRAPH_PRE_COMMIT state
  graph: remove `mapping_idx` and `graph_update_width()`
  graph: reduce duplication in `graph_insert_into_new_columns()`
  graph: reuse `find_new_column_by_commit()`
  graph: handle line padding in `graph_next_line()`
  graph: automatically track display width of graph lines

Merge branch 'jk/cleanup-object-parsing-and-fsck'

Crufty code and logic accumulated over time around the object
parsing and low-level object access used in "git fsck" have been
cleaned up.

* jk/cleanup-object-parsing-and-fsck: (23 commits)
  fsck: accept an oid instead of a "struct tree" for fsck_tree()
  fsck: accept an oid instead of a "struct commit" for fsck_commit()
  fsck: accept an oid instead of a "struct tag" for fsck_tag()
  fsck: rename vague "oid" local variables
  fsck: don't require an object struct in verify_headers()
  fsck: don't require an object struct for fsck_ident()
  fsck: drop blob struct from fsck_finish()
  fsck: accept an oid instead of a "struct blob" for fsck_blob()
  fsck: don't require an object struct for report()
  fsck: only require an oid for skiplist functions
  fsck: only provide oid/type in fsck_error callback
  fsck: don't require object structs for display functions
  fsck: use oids rather than objects for object_name API
  fsck_describe_object(): build on our get_object_name() primitive
  fsck: unify object-name code
  fsck: require an actual buffer for non-blobs
  fsck: stop checking tag->tagged
  fsck: stop checking commit->parent counts
  fsck: stop checking commit->tree value
  commit, tag: don't set parsed bit for parse failures
  ...

built-in add -i: offer the `quit` command

We do not really want to `exit()` here, of course, as this is safely
libified code.

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

built-in add -i: re-implement the `diff` command

It is not only laziness that we simply spawn `git diff -p --cached`
here: this command needs to use the pager, and the pager needs to exit
when the diff is done. Currently we do not have any way to make that
happen if we run the diff in-process. So let's just spawn.

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

built-in add -i: implement the `patch` command

Well, it is not a full implementation yet. In the interest of making
this easy to review (and easy to keep bugs out), we still hand off to
the Perl script to do the actual work.

The `patch` functionality actually makes up for more than half of the
1,800+ lines of `git-add--interactive.perl`. It will be ported from Perl
to C incrementally, later.

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

built-in add -i: re-implement `add-untracked` in C

This is yet another command, ported to C. It builds nicely on the
support functions introduced for other commands, with the notable
difference that only names are displayed for untracked files, no
file type or diff summary.

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

built-in add -i: re-implement `revert` in C

This is a relatively straight-forward port from the Perl version, with
the notable exception that we imitate `git reset -- <paths>` in the C
version rather than the convoluted `git ls-tree HEAD -- <paths> | git
update-index --index-info` followed by `git update-index --force-remove
-- <paths>` for the missed ones.

While at it, we fix the pretty obvious bug where the `revert` command
offers to unstage files that do not have staged changes.

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

built-in add -i: implement the `update` command

After `status` and `help`, it is now time to port the `update` command
to C, the second command that is shown in the main loop menu of `git add
-i`.

This `git add -i` command is the first one which lets the user choose a
subset of a list of files, and as such, this patch lays the groundwork
for the other commands of that category:

- It teaches the `print_file_item()` function to show a unique prefix
  if we found any (the code to find it had been added already in the
  previous patch where we colored the unique prefixes of the main loop
  commands, but that patch uses the `print_command_item()` function to
  display the menu items).

- This patch also adds the help text that is shown when the user input
  to select items from the shown list could not be parsed.

- As `get_modified_files()` clears the list of files, it now has to take
  care of clearing the _full_ `prefix_item_list` lest the `sorted` and
  `selected` fields go stale and inconsistent.

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

built-in add -i: prepare for multi-selection commands

The `update`, `revert` and `add-untracked` commands allow selecting
multiple entries. Let's extend the `list_and_choose()` function to
accommodate those use cases.

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

built-in add -i: allow filtering the modified files list

In the `update` command of `git add -i`, we are primarily interested in the
list of modified files that have worktree (i.e. unstaged) changes.

At the same time, we need to determine _also_ the staged changes, to be
able to produce the full added/deleted information.

The Perl script version of `git add -i` has a parameter of the
`list_modified()` function for that matter. In C, we can be a lot more
precise, using an `enum`.

The C implementation of the filter also has an easier time to avoid
unnecessary work, simply by using an adaptive order of the `diff-index`
and `diff-files` phases, and then skipping files in the second phase
when they have not been seen in the first phase.

Seeing as we change the meaning of the `phase` field, we rename it to
`mode` to reflect that the order depends on the exact invocation of the
`git add -i` command.

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

add-interactive: make sure to release `rev.prune_data`

During a review, Junio Hamano pointed out that the `rev.prune_data` was
copied from another pathspec but never cleaned up.

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

mingw: do set `errno` correctly when trying to restrict handle inheritance

In 9a780a384de (mingw: spawned processes need to inherit only standard
handles, 2019-11-22), we taught the Windows-specific part to restrict
which file handles are passed on to the spawned processes.

Since this logic seemed to be a bit fragile across Windows versions (we
_still_ support Windows Vista in Git for Windows, for example), a
fall-back was added to try spawning the process again, this time without
restricting which file handles are to be inherited by the spawned
process.

In the common case (i.e. when the process could not be spawned for
reasons _other_ than the file handle inheritance), the fall-back attempt
would still fail, of course.

Crucially, one thing we missed in that code path was to set `errno`
appropriately.

This should have been caught by t0061.2 which expected `errno` to be
`ENOENT` after trying to start a process for a non-existing executable,
but `errno` was set to `ENOENT` prior to the `CreateProcessW()` call:
while looking for the config settings for trace2, Git tries to access
`xdg_config` and `user_config` via `access_or_die()`, and as neither of
those config files exists when running the test case (because in Git's
test suite, `HOME` points to the test directory), the `errno` has the
expected value, but for the wrong reasons.

Let's fix that by making sure that `errno` is set correctly. It even
appears that `errno` was set in the _wrong_ case previously:
`CreateProcessW()` returns non-zero upon success, but `errno` was set
only in the non-zero case.

It would be nice if we could somehow fix t0061 to make sure that this
does not regress again. One approach that seemed like it should work,
but did not, was to set `errno` to 0 in the test helper that is used by
t0061.2.

However, when `mingw_spawnvpe()` wants to see whether the file in
question is a script, it calls `parse_interpreter()`, which in turn
tries to `open()` the file. Obviously, this call fails, and sets `errno`
to `ENOENT`, deep inside the call chain started from that test helper.

Instead, we force re-set `errno` at the beginning of the function
`mingw_spawnve_fd()`, which _should_ be safe given that callers of that
function will want to look at `errno` if -1 was returned. And if that
`errno` is 0 ("No error"), regression tests like t0061.2 will kick in.

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

grep: don't return an expression from pcre2_free()

Previously, the void pcre2_free() function in grep.c returned free().
While free() itself is void, afaict it's still an expression as per
section A.2.3, subsection 6.8.6 (jump-statement) in both C99 [1] and C11
[2]:

> return expression

Section 6.8.6.4 in C99 [1] and C11 [2] says that:

> A return statement with an expression shall not appear in a function
> whose return type is void.

The consequence of the old behavior was that developer builds with
pedantic errors enabled broke Git if PCRE2 was enabled and a
smart-enough compiler to detect these errors was used.  This commit
fixes pedantic builds of Git that enables --with-libpcre.

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
[2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf

Signed-off-by: Hans Jerry Illikainen <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9001: avoid including non-trailing NUL bytes in variables

In this test, we have a command substitution whose output starts with a
NUL byte.  bash and dash strip out any NUL bytes from the output; zsh
does not.  As a consequence, zsh fails this test, since the command line
argument we use the variable in is truncated by the NUL byte.

POSIX says of a command substitution that if "the output contains any
null bytes, the behavior is unspecified," so all of the shells are in
compliance with POSIX.  To make our code more portable, let's avoid
prefacing our variables with NUL bytes and instead leave only the
trailing one behind.

Signed-off-by: brian m. carlson <redacted>
Signed-off-by: Junio C Hamano <redacted>

gpg-interface: prefer check_signature() for GPG verification

This commit refactors the use of verify_signed_buffer() outside of
gpg-interface.c to use check_signature() instead.  It also turns
verify_signed_buffer() into a file-local function since it's now only
invoked internally by check_signature().

There were previously two globally scoped functions used in different
parts of Git to perform GPG signature verification:
verify_signed_buffer() and check_signature().  Now only
check_signature() is used.

The verify_signed_buffer() function doesn't guard against duplicate
signatures as described by Michał Górny [1].  Instead it only ensures a
non-erroneous exit code from GPG and the presence of at least one
GOODSIG status field.  This stands in contrast with check_signature()
that returns an error if more than one signature is encountered.

The lower degree of verification makes the use of verify_signed_buffer()
problematic if callers don't parse and validate the various parts of the
GPG status message themselves.  And processing these messages seems like
a task that should be reserved to gpg-interface.c with the function
check_signature().

Furthermore, the use of verify_signed_buffer() makes it difficult to
introduce new functionality that relies on the content of the GPG status
lines.

Now all operations that does signature verification share a single entry
point to gpg-interface.c.  This makes it easier to propagate changed or
additional functionality in GPG signature verification to all parts of
Git, without having odd edge-cases that don't perform the same degree of
verification.

[1] https://dev.gentoo.org/~mgorny/articles/attack-on-git-signature-verification.html

Signed-off-by: Hans Jerry Illikainen <redacted>
Signed-off-by: Junio C Hamano <redacted>

t4210: skip i18n tests that don't work on FreeBSD

A number of t4210-log-i18n tests added in 4e2443b181 set LC_ALL to a UTF-8
locale (is_IS.UTF-8) but then pass an invalid UTF-8 string to --grep.
FreeBSD's regcomp() fails in this case with REG_ILLSEQ, "illegal byte
sequence," which git then passes to die():

fatal: command line: '�': illegal byte sequence

When these tests were added the commit message stated:

| It's possible that this
| test breaks the "basic" and "extended" backends on some systems that
| are more anal than glibc about the encoding of locale issues with
| POSIX functions that I can remember

which seems to be the case here.

Extend test-lib.sh to add a REGEX_ILLSEQ prereq, set it on FreeBSD, and
add !REGEX_ILLSEQ to the two affected tests.

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

archive-zip.c: switch to reentrant localtime_r

Originally, git was intended to be single-thread executable.
`localtime(3)' can be used in such codebase for cleaner code.

Overtime, we're employing multithread in our code base.

Let's phase out `gmtime(3)' in favour of `localtime_r(3)'.

Signed-off-by: Doan Tran Cong Danh <redacted>
Signed-off-by: Junio C Hamano <redacted>

date.c: switch to reentrant {gm,local}time_r

Originally, git was intended to be single-thread executable.
`gmtime(3)' and `localtime(3)' can be used in such codebase
for cleaner code.

Overtime, we're employing multithread in our code base.

Let's phase out `gmtime(3)' and `localtime(3)' in favour of
`gmtime_r(3)' and `localtime_r(3)'.

Signed-off-by: Doan Tran Cong Danh <redacted>
Signed-off-by: Junio C Hamano <redacted>

t7811: don't create unused file

The file "empty" became unused with 1c5e94f459 (tests: use
'test_must_be_empty' instead of 'test_cmp <empty> <out>', 2018-08-19);
get rid of it.

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

t9300: don't create unused file

The file "frontend" became unused with 4de0bbd898 (t9300: use perl
"head -c" clone in place of "dd bs=1 count=16000" kluge, 2010-12-13);
get rid of it.

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

sequencer: fix a memory leak in sequencer_continue()

When continuing an interactive rebase after a merge conflict was solved,
if the resolution could not be committed, sequencer_continue() would
return early without releasing its todo list, resulting in a memory
leak.  This plugs this leak by jumping to the end of the function, where
the todo list is deallocated.

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

doc: replace public-inbox links with lore.

Since we're now recommending lore.kernel.org (and because the
public-inbox.org domain might eventually go away), let's update our
internal references to use it, too. That future-proofs our references,
and sets the example we want people to follow.

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

doc: recommend lore. over public-inbox.org

Since lore.kernel.org now has the same archive as public-inbox.org and
may have more longevity going forward[1], let's recommend people use it
for finding or referencing messages.

[1] https://public-inbox.org/git/20191120195556.GA25189@dcvr/
      or if you like:
    https://lore.kernel.org/git/20191120195556.GA25189@dcvr/

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

send-pack: use OBJECT_INFO_QUICK to check negative objects

When pushing, we feed pack-objects a list of both positive and negative
objects. The positive objects are what we want to send, and the negative
objects are what the other side told us they have, which we can use to
limit the size of the push.

Before passing along a negative object, send_pack() will make sure we
actually have it (since we only know about it because the remote
mentioned it, not because it's one of our refs). So it's expected that
some of these objects will be missing on the local side. But looking for
a missing object is more expensive than one that we have: it triggers
reprepare_packed_git() to handle a racy repack, plus it has to explore
every alternate's loose object tree (which can be slow if you have a lot
of them, or have a high-latency filesystem).

This isn't usually a big problem, since repositories you're pushing to
don't generally have a large number of refs that are unrelated to what
the client has. But there's no reason such a setup is wrong, and it
currently performs poorly.

We can fix this by using OBJECT_INFO_QUICK, which tells the lookup
code that we expect objects to be missing. Notably, it will not re-scan
the packs, and it will use the loose cache from 61c7711cfe (sha1-file:
use loose object cache for quick existence check, 2018-11-12).

The downside is that in the rare case that we race with a local repack,
we might fail to feed some objects to pack-objects, making the resulting
push larger. But we'd never produce an invalid or incorrect push, just a
less optimal one. That seems like a reasonable tradeoff, and we already
do similar things on the fetch side (e.g., when marking COMPLETE
commits).

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

t7700: s/test -f/test_path_is_file/

Since we have debugging-friendly alternatives to `test -f`, replace
instances of `test -f` with `test_path_is_file` so that if a command
ever fails, we get better debugging information.

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

t7700: move keywords onto their own line

The code style for tests is to have statements on their own line if
possible. Move keywords onto their own line so that they conform with
the test style.

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

t7700: remove spaces after redirect operators

For shell scripts, the usual convention is for there to be no space
after redirection operators, (e.g. `>file`, not `> file`). Remove these
spaces wherever they appear.

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

t7700: drop redirections to /dev/null

Since output is silenced when running without `-v` and debugging output
is useful with `-v`, remove redirections to /dev/null as it is not
useful.

In one case where the output of stdout is consumed, redirect the output
of test_commit to stderr.

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

t7501: stop losing return codes of git commands

In a pipe, only the return code of the last command is used. Thus, all
other commands will have their return codes masked. Rewrite pipes so
that there are no git commands upstream so that we will know if a
command fails.

In the 'interactive add' test case, we prepend a `test_must_fail` to
`git commit --interactive`. When there are no changes to commit,
`git commit` will exit with status code 1. Following along with the rest
of the file, we use `test_must_fail` to test for this case.

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

t7501: remove spaces after redirect operators

For shell scripts, the usual convention is for there to be no space
after redirection operators, (e.g. `>file`, not `> file`). Remove these
spaces wherever they appear.

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

t5703: stop losing return codes of git commands

Currently, there are two ways where the return codes of git commands are
lost. The first way is when a command is in the upstream of a pipe. In a
pipe, only the return code of the last command is used. Thus, all other
commands will have their return codes masked. Rewrite pipes so that
there are no git commands upstream.

The other way is when a command is in a non-assignment command
substitution. The return code will be lost in favour of the surrounding
command's. Rewrite instances of this such that git commands are in an
assignment-only command substitution.

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

t5703: simplify one-time-sed generation logic

In inconsistency(), we had two `git rev-parse` invocations in the
upstream of a pipe within a command substitution. In case this
invocation ever failed, its exit code would be swallowed up and we would
not know about it.

Pull the command substitutions out into variable assignments so that
their return codes are not lost.

Drop the pipe into `tr` because the $(...) substitution already takes
care of stripping out newlines, so the `tr` invocations in the code are
superfluous.

Finally, given the way the tests actually employ "one-time-sed" via
$(cat one-time-sed) in t/lib-httpd/apply-one-time-sed.sh, convert the
`printf` into an `echo`. This makes it consistent with the final "server
loses a ref - ref in want" test, which does use `echo` rather than
`printf`.

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

t5317: use ! grep to check for no matching lines

Several times in t5317, we would use `wc -l` to ensure that a grep
result is empty. However, grep already has a way to do that... Its
return code! Use `! grep` in the cases where we are ensuring that there
are no matching lines.

While at it, drop unnecessary invocations of `awk` and `sort` in each
affected test since those commands do not influence the outcome. It's
not clear why that extra work was being done in the first place, and the
code's history doesn't shed any light on the matter since these tests
were simply born this way[1], likely due to copy-paste programming. The
unnecessary work wasn't noticed even when the code was later touched for
various cleanups[2][3].

[1]: 9535ce7337 (pack-objects: add list-objects filtering, 2017-11-21)
[2]: bdbc17e86a (tests: standardize pipe placement, 2018-10-05)
[3]: 61de0ff695 (tests: don't swallow Git errors upstream of pipes, 2018-10-05)

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

t5317: stop losing return codes of git commands

Currently, there are two ways where the return codes of git commands are
lost. The first way is when a command is in the upstream of a pipe. In a
pipe, only the return code of the last command is used. Thus, all other
commands will have their return codes masked. Rewrite pipes so that
there are no git commands upstream.

The other way is when a command is in a non-assignment command
substitution. The return code will be lost in favour of the surrounding
command's. Rewrite instances of this such that git commands output to a
file and surrounding commands only call command substitutions with
non-git commands.

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

t4138: stop losing return codes of git commands

In a pipe, only the return code of the last command is used. Thus, all
other commands will have their return codes masked. Rewrite pipes so
that there are no git commands upstream so that we will know if a
command fails.

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

t4015: use test_write_lines()

Instead of rolling our own method to write out some lines into a file,
use the existing test_write_lines().

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

t4015: stop losing return codes of git commands

Currently, there are two ways where the return codes of git commands are
lost. The first way is when a command is in the upstream of a pipe. In a
pipe, only the return code of the last command is used. Thus, all other
commands will have their return codes masked. Rewrite pipes so that
there are no git commands upstream.

The other way is when a command is in a non-assignment command
substitution. The return code will be lost in favour of the surrounding
command's. Rewrite instances of this so that git commands are either run
on their own or in an assignment-only command substitution.

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

t3600: comment on inducing SIGPIPE in `git rm`

Add a comment about intentionally inducing SIGPIPE since this is unusual
and future developers should be aware. Also, even though we are trying
to refactor git commands out of the upstream of pipes, we cannot do it
here since we rely on it being upstream to induce SIGPIPE. Comment on
that as well so that future developers do not try to change it.

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

t3600: stop losing return codes of git commands

When a command is in a non-assignment command substitution, the return
code will be lost in favour of the surrounding command's. As a result,
if a git command fails, we won't know about it. Rewrite instances of
this so that git commands are either run in an assignment-only command
substitution so that their return codes aren't lost.

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

t3600: use test_line_count() where possible

Since we have a helper function that can test the number of lines in a
file that gives better debugging information on failure, use
test_line_count() to test the number of lines.

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

t3301: stop losing return codes of git commands

Currently, there are two ways where the return codes of git commands are
lost. The first way is when a command is in the upstream of a pipe. In a
pipe, only the return code of the last command is used. Thus, all other
commands will have their return codes masked. Rewrite pipes so that
there are no git commands upstream.

The other way is when a command is in a non-assignment command
substitution. The return code will be lost in favour of the surrounding
command's. Rewrite instances of this so that git commands are either run
on their own or in an assignment-only command substitution.

This patch fixes a real buggy test: in 'copy note with "git notes
copy"', `git notes` was mistyped as `git note`.

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

t0090: stop losing return codes of git commands

In generate_expected_cache_tree_rec(), there are currently two instances
of `git ls-files` in the upstream of a pipe. In the case where the
upstream git command fails, its return code will be lost. Extract the
`git ls-files` into its own call so that if it ever fails, its return
code is not lost.

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

t0014: remove git command upstream of pipe

Before, the `git frotz` command would fail but its return code was
hidden since it was in the upstream of a pipe. Break the pipeline into
two commands so that the return code is no longer lost. Also, mark
`git frotz` with test_must_fail since it's supposed to fail.

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

apply-one-time-sed.sh: modernize style

Convert `[ ... ]` to use `test` and test for the existence of a regular
file (`-f`) instead of any file (`-e`).

Move the `then`s onto their own lines so that it conforms with the
general test style.

Instead of redirecting input into sed, allow it to open its own input.

Use `cmp -s` instead of `diff` since we only care about whether the two
files are equal and `diff` is overkill for this.

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

ci: build Git with GCC 9 in the 'osx-gcc' build job

Our 'osx-gcc' build job on Travis CI relied on GCC 8 being installed
(but not linked) in the image we use [1].  Alas, since the last update
of this image a few days ago this is not the case anymore, and now it
contains GCC 9 (installed and linked) instead of GCC 8.  The results
are failed 'osx-gcc' jobs, because they can't find the 'gcc-8' command
[2].

Let's move on to use GCC 9, with hopefully better error reporting and
improved -Wfoo flags and what not.  On Travis CI this has the benefit
that we can spare a few seconds while installing dependencies, because
it already comes pre-installed, at least for now.  The Azure Pipelines
OSX image doesn't include GCC, so we have to install it ourselves
anyway, and then we might as well install the newer version.

In a vain attempt I tried to future-proof this a bit:

  - Install 'gcc@9' specifically, so we'll still get what we want even
    after GCC 10 comes out, and the "plain" 'gcc' package starts to
    refer to 'gcc@10'.

  - Run both 'brew install gcc@9' and 'brew link gcc@9'.  If 'gcc@9'
    is already installed and linked, then both commands are noop and
    exit with success.  But as we saw in the past, sometimes the image
    contains the expected GCC package installed but not linked, so
    maybe it will happen again in the future as well.  In that case
    'brew install' is still a noop, and instructs the user to run
    'brew link' instead, so that's what we'll do.  And if 'gcc@9' is
    not installed, then 'brew install' will install it, and the
    subsequent 'brew link' becomes a noop.

An additional benefit of this patch is that from now on we won't
unnecessarily install GCC and its dependencies in the 'osx-clang' jobs
on Azure Pipelines.

[1] 7d4733c501 (ci: fix GCC install in the Travis CI GCC OSX job,
    2019-10-24)
[2] https://travis-ci.org/git/git/jobs/615442297#L333

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

test: use test_must_be_empty F instead of test_cmp empty F

Use test_must_be_empty instead of comparing it to an empty file.  That's
more efficient, as the function only needs built-in meta-data only check
in the usual case, and provides nicer debug output otherwise.

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

t7812: add missing redirects

Two tests in t7812, added in 8a599983 ("grep: stess test PCRE v2 on
invalid UTF-8 data", 2019-07-26), were missing redirects, failing to
actually test the produced output.

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

test: use test_must_be_empty F instead of test -z $(cat F)

Use test_must_be_empty instead of reading the file and comparing its
contents to an empty string.  That's more efficient, as the function
only needs built-in meta-data only check in the usual case, and provides
nicer debug output otherwise.

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

t1400: use test_must_be_empty

Use test_must_be_empty instead of reading the file and comparing its
contents to an empty string.  That's more efficient, as the function
only needs built-in meta-data only check in the usual case, and provides
nicer debug output otherwise.

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

t1410: use test_line_count

Use test_line_count to check if the number of lines matches
expectations, for improved consistency and nicer debug output.

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

t1512: use test_line_count

Use test_line_count to check if the number of lines matches
expectations, for improved consistency and nicer debug output.

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

run-command: use prepare_git_cmd() in prepare_cmd()

Call prepare_git_cmd() instead of open-coding it.

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

name-rev: use skip_prefix() instead of starts_with()

Let skip_prefix() advance refname to get rid of two magic numbers.

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

push: use skip_prefix() instead of starts_with()

Get rid of a magic number by using skip_prefix().

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

shell: use skip_prefix() instead of starts_with()

Get rid of a magic number by using skip_prefix() instead of
starts_with().

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

fmt-merge-msg: use skip_prefix() instead of starts_with()

Get rid of two magic numbers by using skip_prefix().

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

fetch: use skip_prefix() instead of starts_with()

Get rid of magic numbers by letting skip_prefix() set the pointer
"what".

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

t5150: skip request-pull test if Perl is disabled

The git-request-pull.sh script invokes Perl, so it requires Perl to be
available, but the associated test t5150 does not skip itself when Perl
has been disabled, which then makes subtest 4 through 10 fail. Subtest 3
still passes, but for the wrong reasons (it expects git-request-pull to
fail, and it does fail when Perl is not available). The initial two
subtests that do pass are only doing setup.

To prevent t5150 from failing the build when NO_PERL=1, add a check that
sets skip_all when "! test_have_prereq PERL", just like how for example
t3701-add-interactive skips itself when Perl has been disabled.

Signed-off-by: Ruud van Asseldonk <redacted>
Reviewed-by: Jonathan Nieder <redacted>
Signed-off-by: Junio C Hamano <redacted>

commit-graph: use start_delayed_progress()

When writing a commit-graph, we show progress along several commit
walks. When we use start_delayed_progress(), the progress line will
only appear if that step takes a decent amount of time.

However, one place was missed: computing generation numbers. This is
normally a very fast operation as all commits have been parsed in a
previous step. But, this is showing up for all users no matter how few
commits are being added.

The tests that check for the progress output have already been updated
to use GIT_PROGRESS_DELAY=0 to force the expected output.

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

progress: create GIT_PROGRESS_DELAY

The start_delayed_progress() method is a preferred way to show
optional progress to users as it ignores steps that take less
than two seconds. However, this makes testing unreliable as tests
expect to be very fast.

In addition, users may want to decrease or increase this time
interval depending on their preferences for terminal noise.

Create the GIT_PROGRESS_DELAY environment variable to control
the delay set during start_delayed_progress(). Set the value
in some tests to guarantee their output remains consistent.

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

t/perf: don't depend on Git.pm

The perf suite's aggregate.perl depends on Git.pm, which is a mild
annoyance if you've built git with NO_PERL. It turns out that the only
thing we use it for is a single call of the command_oneline() helper.
We can just replace this with backticks or similar.

Annoyingly, perl has no backtick equivalent that avoids a shell eval,
which means our $arg would require quoting. This probably doesn't matter
for our purposes, but it's better to be safe and model good style. So
we'll just provide a short helper around open(), which takes its
arguments as a list.

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

perf-lib: use a single filename for all measurement types

The perf tests write files recording the results of tests.  These
results are later aggregated by 'aggregate.perl'.  If the tests are run
multiple times, those results are overwritten by the new results.  This
works just fine as long as there are only perf tests measuring the
times, whose results are stored in "$base".times files.

However 22bec79d1a ("t/perf: add infrastructure for measuring sizes",
2018-08-17) introduced a new type of test for measuring the size of
something.  The results of this are written to "$base".size files.

"$base" is essentially made up of the basename of the script plus the
test number.  So if test numbers shift because a new test was
introduced earlier in the script we might end up with both a ".times"
and a ".size" file for the same test.  In the aggregation script the
".times" file is preferred over the ".size" file, so some size tests
might end with performance numbers from a previous run of the test.

This is mainly relevant when writing perf tests that check both
performance and sizes, and can get quite confusing during
developement.

We could fix this by doing a more thorough job of cleaning out old
".times" and ".size" files before running each test. However, an even
easier solution is to just use the same filename for both types of
measurement, meaning we'll always overwrite the previous result. We
don't even need to change the file format to distinguish the two;
aggregate.perl already decides which is which based on a regex of the
content (this may become ambiguous if we add new types in the future,
but we could easily add a header field to the file at that point).

Based on an initial patch from Thomas Gummerer, who discovered the
problem and did all of the analysis (which I stole for the commit
message above):

  https://public-inbox.org/git/20191119185047.8550-1-t.gummerer@gmail.com/

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

test-lib-functions: suppress a 'git rev-parse' error in 'test_commit_bulk'

When 'test_commit_bulk' is invoked in an empty test repository, it
prints a "fatal: Needed a single revision" error, but still does what
it's supposed to do.  A test helper function displaying a fatal error
and still succeeding is always suspect to be buggy, but luckily that's
not the case here: that error comes from a 'git rev-parse --verify
HEAD' command invoked in a condition, which doesn't have anything to
verify in an empty repository.

Use the '--quiet' option to suppress that error message.

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

rebase -i: finishing touches to --reset-author-date

Clarify the way the `--reset-author-date` option is described,
and mark its usage string translatable.

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

submodule: fix 'submodule status' when called from a subdirectory

When calling `git submodule status` while in a subdirectory, we are
incorrectly not detecting modified submodules and
thus reporting that all of the submodules are unchanged.

This is because the submodule helper is calling `diff-index` with the
submodule path assuming the path is relative to the current prefix
directory, however the submodule path used is actually relative to the root.

Always pass NULL as the `prefix` when running diff-files on the
submodule, to make sure the submodule's path is interpreted as relative
to the superproject's repository root.

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

sequencer: directly call pick_commits() from complete_action()

Currently, complete_action(), used by builtin/rebase.c to start a new
rebase, calls sequencer_continue() to do it.  Before the former calls
pick_commits(), it

 - calls read_and_refresh_cache() -- this is unnecessary here as we've
   just called require_clean_work_tree() in complete_action()
 - calls read_populate_opts() -- this is unnecessary as we're starting a
   new rebase, so `opts' is fully populated
 - loads the todo list -- this is unnecessary as we've just populated
   the todo list in complete_action()
 - commits any staged changes -- this is unnecessary as we're starting a
   new rebase, so there are no staged changes
 - calls record_in_rewritten() -- this is unnecessary as we're starting
   a new rebase.

This changes complete_action() to directly call pick_commits() to avoid
these unnecessary steps.

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

rebase: fill `squash_onto' in get_replay_opts()

When sequencer_continue() is called by complete_action(), `opts' has
been filled by get_replay_opts().  Currently, it does not initialise the
`squash_onto' field (used by the `--root' mode), only
read_populate_opts() does.  It’s not a problem yet since
sequencer_continue() calls it before pick_commits(), but it would lead
to incorrect results once complete_action() is modified to call
pick_commits() directly.

Let’s change that.

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

sequencer: move the code writing total_nr on the disk to a new function

The total number of commands can be used to show the progression of the
rebasing in a shell.  It is written to the disk by read_populate_todo()
when the todo list is loaded from sequencer_continue() or
pick_commits(), but not by complete_action().

This moves the part writing total_nr to a new function so it can be
called from complete_action().

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

sequencer: update `done_nr' when skipping commands in a todo list

In a todo list, `done_nr' is the number of commands that were executed
or skipped, but skip_unnecessary_picks() did not update it.

This variable is mostly used by command prompts (ie. git-prompt.sh and
the like).  As in the previous commit, this inconsistent behaviour is
not a problem yet, but it would start to matter at the end of this
series the same reason.

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

sequencer: update `total_nr' when adding an item to a todo list

`total_nr' is the total number of items, counting both done and todo,
that are in a todo list.  But unlike `nr', it was not updated when an
item was appended to the list.

This variable is mostly used by command prompts (ie. git-prompt.sh and
the like).  By forgetting to update it, the original code made it not
reflect the reality, but this flaw was masked by the code calling
unnecessarily read_populate_todo() again to update the variable to its
correct value.  At the end of this series, the unnecessary call will be
removed, and the inconsistency addressed by this patch would start to
matter.

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

revision: free topo_walk_info before creating a new one in init_topo_walk

init_topo_walk doesn't reuse an existing topo_walk_info, and currently
leaks the one that might exist on the current rev_info if it was already
used for a topo walk beforehand.

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

revision: clear the topo-walk flags in reset_revision_walk

Not doing so can lead to wrong topo-walks when using the revision walk API
consecutively.

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

git-compat-util.h: drop the `PRIuMAX` and other fallback definitions

Git's code base already seems to be using `PRIdMAX` without any such
fallback definition for quite a while (75459410edd (json_writer: new
routines to create JSON data, 2018-07-13), to be precise, and the
first Git version to include that commit was v2.19.0).  Having a
fallback definition only for `PRIuMAX` is a bit inconsistent.

We do sometimes get portability reports more than a year after the
problem was introduced.  This one should be fairly safe.  PRIuMAX is
in C99 (for that matter, SCNuMAX, PRIu32 and others also are), and
we've been picking up other C99-isms without complaint.

The PRIuMAX fallback definition was originally added in 3efb1f343a
(Check for PRIuMAX rather than NO_C99_FORMAT in fast-import.c.,
2007-02-20). But it was replacing a construct that was introduced in
an even earlier commit, 579d1fbfaf (Add NO_C99_FORMAT to support
older compilers., 2006-07-30), which talks about gcc 2.95.

That's pretty ancient at this point.

Signed-off-by: Hariom Verma <redacted>
Helped-by: Jeff King <redacted>
[jc: tweaked both message and code, taking what peff wrote]
Signed-off-by: Junio C Hamano <redacted>

l10n: zh_TW: add translation for v2.24.0

Based on commit a5cd71ca4a ("l10n: zh_CN: for git v2.24.0 l10n round
1~2", 2019-10-29).

Signed-off-by: Yi-Jyun Pan <redacted>
Reviewed-by: Franklin Weng <redacted>
Signed-off-by: Jiang Xin <redacted>

reset: parse rev as tree-ish in patch mode

Since 2f328c3d ("reset $sha1 $pathspec: require $sha1 only to be
treeish", 2013-01-14), we allowed "git reset $object -- $path" to reset
individual paths that match the pathspec to take the blob from a tree
object, not necessarily a commit, while the form to reset the tip of the
current branch to some other commit still must be given a commit.

Like resetting with paths, "git reset --patch" does not update HEAD, and
need not require a commit. The path-filtered form, "git reset --patch
$object -- $pathspec", has accepted a tree-ish since 2f328c3d.

"git reset --patch" is documented as accepting a <tree-ish> since
bf44142f ("reset: update documentation to require only tree-ish with
paths", 2013-01-16). Documentation changes are not required.

Loosen the restriction that requires a commit for the unfiltered "git
reset --patch $object".

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

doc: mention that 'git submodule update' fetches missing commits

'git submodule update' will fetch new commits from the submodule remote
if the SHA-1 recorded in the superproject is not found. This was not
mentioned in the documentation.

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

doc: document 'git submodule status --cached'

'git submodule status --cached' reports the SHAs recorded in the
index of the superproject, instead of the SHAs that are checked out
in the submodule.

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

sequencer: don't re-read todo for revert and cherry-pick

When 'git revert' or 'git cherry-pick --edit' is invoked with multiple
commits, then after editing the first commit message is finished both
these commands should continue with processing the second commit and
launch another editor for its commit message, assuming there are
no conflicts, of course.

Alas, this inadvertently changed with commit a47ba3c777 (rebase -i:
check for updated todo after squash and reword, 2019-08-19): after
editing the first commit message is finished, both 'git revert' and
'git cherry-pick --edit' exit with error, claiming that "nothing to
commit, working tree clean".

The reason for the changed behaviour is twofold:

  - Prior to a47ba3c777 the up-to-dateness of the todo list file was
    only checked after 'exec' instructions, and that commit moved
    those checks to the common code path.  The intention was that this
    check should be performed after instructions spawning an editor
    ('squash' and 'reword') as well, so the ongoing 'rebase -i'
    notices when the user runs a 'git rebase --edit-todo' while
    squashing/rewording a commit message.

    However, as it happened that check is now performed even after
    'revert' and 'pick' instructions when they involved editing the
    commit message.  And 'revert' by default while 'pick' optionally
    (with 'git cherry-pick --edit') involves editing the commit
    message.

  - When invoking 'git revert' or 'git cherry-pick --edit' with
    multiple commits they don't read a todo list file but assemble the
    todo list in memory, thus the associated stat data used to check
    whether the file has been updated is all zeroed out initially.

    Then the sequencer writes all instructions (including the very
    first) to the todo file, executes the first 'revert/pick'
    instruction, and after the user finished editing the commit
    message the changes of a47ba3c777 kick in, and it checks whether
    the todo file has been modified.  The initial all-zero stat data
    obviously differs from the todo file's current stat data, so the
    sequencer concludes that the file has been modified.  Technically
    it is not wrong, of course, because the file just has been written
    indeed by the sequencer itself, though the file's contents still
    match what the sequencer was invoked with in the beginning.
    Consequently, after re-reading the todo file the sequencer
    executes the same first instruction _again_, thus ending up in
    that "nothing to commit" situation.

The todo list was never meant to be edited during multi-commit 'git
revert' or 'cherry-pick' operations, so perform that "has the todo
file been modified" check only when the sequencer was invoked as part
of an interactive rebase.

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

mingw: restrict file handle inheritance only on Windows 7 and later

Turns out that it don't work so well on Vista, see
https://github.com/git-for-windows/git/issues/1742 for details.

According to https://devblogs.microsoft.com/oldnewthing/?p=8873, it
*should* work on Windows Vista and later.

But apparently there are issues on Windows Vista when pipes are
involved. Given that Windows Vista is past its end of life (official
support ended on April 11th, 2017), let's not spend *too* much time on
this issue and just disable the file handle inheritance restriction on
any Windows version earlier than Windows 7.

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