Merge branch 'js/win32-mmap' into HEAD

mmap emulation on Windows has been optimized and work better without
consuming paging store when not needed.

* js/win32-mmap:
  mmap(win32): avoid expensive fstat() call
  mmap(win32): avoid copy-on-write when it is unnecessary
  win32mmap: set errno appropriately

Merge branch 'jk/push-client-deadlock-fix' into HEAD

Some Windows SDK lacks pthread_sigmask() implementation and fails
to compile the recently updated "git push" codepath that uses it.

* jk/push-client-deadlock-fix:
  Windows: only add a no-op pthread_sigmask() when needed
  Windows: add pthread_sigmask() that does nothing
  t5504: drop sigpipe=ok from push tests
  fetch-pack: isolate sigpipe in demuxer thread
  send-pack: isolate sigpipe in demuxer thread
  run-command: teach async threads to ignore SIGPIPE
  send-pack: close demux pipe before finishing async process

Merge branch 'sb/mv-submodule-fix' into HEAD

"git mv old new" did not adjust the path for a submodule that lives
as a subdirectory inside old/ directory correctly.

* sb/mv-submodule-fix:
  mv: allow moving nested submodules

Merge branch 'da/user-useconfigonly' into HEAD

The "user.useConfigOnly" configuration variable makes it an error
if users do not explicitly set user.name and user.email.  However,
its check was not done early enough and allowed another error to
trigger, reporting that the default value we guessed from the
system setting was unusable.  This was a suboptimal end-user
experience as we want the users to set user.name/user.email without
relying on the auto-detection at all.

* da/user-useconfigonly:
  ident: give "please tell me" message upon useConfigOnly error
  ident: check for useConfigOnly before auto-detection of name/email

Merge branch 'ld/p4-test-py3' into HEAD

The test scripts for "git p4" (but not "git p4" implementation
itself) has been updated so that they would work even on a system
where the installed version of Python is python 3.

* ld/p4-test-py3:
  git-p4 tests: time_in_seconds should use $PYTHON_PATH
  git-p4 tests: work with python3 as well as python2
  git-p4 tests: cd to / before running python

cat-file: default to --buffer when --batch-all-objects is used

Traditionally cat-file's batch-mode does not do any output
buffering. The reason is that a caller may have pipes
connected to its input and output, and would want to use
cat-file interactively, getting output immediately for each
input it sends.

This may involve a lot of small write() calls, which can be
slow. So we introduced --buffer to improve this, but we
can't turn it on by default, as it would break the
interactive case above.

However, when --batch-all-objects is used, we do not read
stdin at all. We generate the output ourselves as quickly as
possible, and then exit. In this case buffering is a strict
win, and it is simply a hassle for the user to have to
remember to specify --buffer.

This patch makes --buffer the default when --batch-all-objects
is used. Specifying "--buffer" manually is still OK, and you
can even override it with "--no-buffer" if you're a
masochist (or debugging).

For some real numbers, running:

  git cat-file --batch-all-objects --batch-check='%(objectname)'

on torvalds/linux goes from:

  real    0m1.464s
  user    0m1.208s
  sys     0m0.252s

to:

  real    0m1.230s
  user    0m1.172s
  sys     0m0.056s

for a 16% speedup.

Suggested-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

cat-file: avoid noop calls to sha1_object_info_extended

It is not unreasonable to ask cat-file for a batch-check
format of simply "%(objectname)". At first glance this seems
like a noop (you are generally already feeding the object
names on stdin!), but it has a few uses:

  1. With --batch-all-objects, you can generate a listing of
     the sha1s present in the repository, without any input.

  2. You do not have to feed sha1s; you can feed arbitrary
     sha1 expressions and have git resolve them en masse.

  3. You can even feed a raw sha1, with the result that git
     will tell you whether we actually have the object or
     not.

In case 3, the call to sha1_object_info is useful; it tells
us whether the object exists or not (technically we could
swap this out for has_sha1_file, but the cost is roughly the
same).

In case 2, the existence check is of debatable value. A
mass-resolution might prefer performance to safety (against
outputting a value for a corrupted ref, for example).
However, the object lookup cost is likely not as noticeable
compared to the resolution cost. And since we have provided
that safety in the past, the conservative choice is to keep
it.

In case 1, though, the object lookup is a definite noop; we
know about the object because we found it in the object
database. There is no new information gained by making the
call.

This patch detects that case and optimizes out the call.
Here are best-of-five timings for linux.git:

  [before]
  $ time git cat-file --buffer \
                      --batch-all-objects \
                      --batch-check='%(objectname)'
  real    0m2.117s
  user    0m2.044s
  sys     0m0.072s

  [after]
  $ time git cat-file --buffer \
                      --batch-all-objects \
                      --batch-check='%(objectname)'
  real    0m1.230s
  user    0m1.176s
  sys     0m0.052s

There are two implementation details to note here.

One is that we detect the noop case by seeing that "struct
object_info" does not request any information. But besides
object existence, there is one other piece of information
which sha1_object_info may fill in: whether the object is
cached, loose, or packed. We don't currently provide that
information in the output, but if we were to do so later,
we'd need to take note and disable the optimization in that
case.

And that leads to the second note. If we were to output
that information, a better implementation would be to
remember where we saw the object in --batch-all-objects in
the first place, and avoid looking it up again by sha1.

In fact, we could probably squeeze out some extra
performance for less-trivial cases, too, by remembering the
pack location where we saw the object, and going directly
there to find its information (like type, size, etc). That
would in theory make this optimization unnecessary.

I didn't pursue that path here for two reasons:

  1. It's non-trivial to implement, and has memory
     implications. Because we sort and de-dup the list of
     output sha1s, we'd have to record the pack information
     for each object, too.

  2. It doesn't save as much as you might hope. It saves the
     find_pack_entry() call, but getting the size and type
     for deltified objects requires walking down the delta
     chain (for the real type) or reading the delta data
     header (for the size). These costs tend to dominate the
     non-trivial cases.

By contrast, this optimization is easy and self-contained,
and speeds up a real-world case I've used.

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

t1500: avoid setting environment variables outside of tests

Ideally, each test should be responsible for setting up state it needs
rather than relying upon transient global state. Toward this end, teach
test_rev_parse() to accept a "-g <dir>" option to allow callers to
specify the value of the GIT_DIR environment variable explicitly. Take
advantage of this new option to avoid polluting the global scope with
GIT_DIR assignments.

Implementation note: Typically, tests avoid polluting the global state
by wrapping transient environment variable assignments within a
subshell, however, this technique doesn't work here since test_config()
and test_unconfig() need to know GIT_DIR, as well, but neither function
can be used within a subshell. Consequently, GIT_DIR is instead cleared
manually via test_when_finished().

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1500: avoid setting configuration options outside of tests

Ideally, each test should be responsible for setting up state it needs
rather than relying upon transient global state. Toward this end, teach
test_rev_parse() to accept a "-b <value>" option to allow callers to set
"core.bare" explicitly or undefine it. Take advantage of this new option
to avoid setting "core.bare" outside of tests.

Under the hood, "-b <value>" invokes "test_config -C <dir>" (or
"test_unconfig -C <dir>"), thus git-config knows explicitly where to
find its configuration file. Consequently, the global GIT_CONFIG
environment variable required by the manual git-config invocations
outside of tests is no longer needed, and is thus dropped.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1500: avoid changing working directory outside of tests

Ideally, each test should be responsible for setting up state it needs
rather than relying upon transient global state. Toward this end, teach
test_rev_parse() to accept a "-C <dir>" option to allow callers to
instruct it explicitly in which directory its tests should be run. Take
advantage of this new option to avoid changing the working directory
outside of tests.

Implementation note: test_rev_parse() passes "-C <dir>" along to
git-rev-parse with <dir> properly quoted. The natural and POSIX way to
do so is via ${dir:+-C "$dir"}, however, with some older broken shells,
this expression evaluates incorrectly to a single argument ("-C <dir>")
rather than the expected two (-C and "<dir>"). Work around this problem
with the slightly ungainly expression: ${dir:+-C} ${dir:+"$dir"}

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1500: test_rev_parse: facilitate future test enhancements

Tests run by test_rev_parse() are nearly identical; each invokes
git-rev-parse with a single option and compares the result against an
expected value. Such duplication makes it onerous to extend the tests
since any change needs to be repeated in each test. Avoid the
duplication by parameterizing the test and driving it via a for-loop.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t6044: replace seq by test_seq

seq is not available everywhere.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fast-import: do not truncate exported marks file

Certain lines of the marks file might be corrupted (or the objects
missing due to a garbage collection), but that's no reason to truncate
the file and essentially destroy the rest of it.

Ideally missing objects should not cause a crash, we could just skip
them, but that's another patch.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Thirteenth batch for 2.9

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

Merge branch 'kf/gpg-sig-verification-doc'

Documentation for "git merge --verify-signatures" has been updated
to clarify that the signature of only the commit at the tip is
verified.  Also the phrasing used for signature and key validity is
adjusted to align with that used by OpenPGP.

* kf/gpg-sig-verification-doc:
  Documentation: clarify signature verification

Merge branch 'js/windows-dotgit'

On Windows, .git and optionally any files whose name starts with a
dot are now marked as hidden, with a core.hideDotFiles knob to
customize this behaviour.

* js/windows-dotgit:
  mingw: remove unnecessary definition
  mingw: introduce the 'core.hideDotFiles' setting

Merge branch 'va/mailinfo-doc-typofix'

Typofix.

* va/mailinfo-doc-typofix:
  Documentation/git-mailinfo: fix typo

Merge branch 'jk/test-send-sh-x-trace-elsewhere'

Running tests with '-x' option to trace the individual command
executions is a useful way to debug test scripts, but some tests
that capture the standard error stream and check what the command
said can be broken with the trace output mixed in.  When running
our tests under "bash", however, we can redirect the trace output
to another file descriptor to keep the standard error of programs
being tested intact.

* jk/test-send-sh-x-trace-elsewhere:
  test-lib: set BASH_XTRACEFD automatically

Merge branch 'js/http-custom-headers'

Update tests for "http.extraHeaders=<header>" to be portable back
to Apache 2.2 (the original depended on <RequireAll/> which is a
more recent feature).

* js/http-custom-headers:
  submodule: ensure that -c http.extraheader is heeded
  t5551: make the test for extra HTTP headers more robust
  tests: adjust the configuration for Apache 2.2

Merge branch 'jk/rebase-interative-eval-fix'

Portability enhancement for "rebase -i" to help platforms whose
shell does not like "for i in <empty>" (which is not POSIX-kosher).

* jk/rebase-interative-eval-fix:
  rebase--interactive: avoid empty list in shell for-loop

Merge branch 'jc/fsck-nul-in-commit'

"git fsck" learned to catch NUL byte in a commit object as
potential error and warn.

* jc/fsck-nul-in-commit:
  fsck: detect and warn a commit with embedded NUL
  fsck_commit_buffer(): do not special case the last validation

Merge branch 'nd/test-helpers'

Switching between 'master' and 'next', between which the paths to
test helper binaries have changed, did not update bin-wrappers/*
scripts used in tests, causing false test failures.

* nd/test-helpers:
  wrap-for-bin.sh: regenerate bin-wrappers when switching branches

Merge branch 'ls/travis-build-doc'

CI test was taught to build documentation pages.

* ls/travis-build-doc:
  travis-ci: build documentation

Merge branch 'jc/ll-merge-internal'

"git rerere" can get confused by conflict markers deliberately left
by the inner merge step, because they are indistinguishable from
the real conflict markers left by the outermost merge which are
what the end user and "rerere" need to look at.  This was fixed by
making the conflict markers left by the inner merges a bit longer.

* jc/ll-merge-internal:
  t6036: remove pointless test that expects failure
  ll-merge: use a longer conflict marker for internal merge
  ll-merge: fix typo in comment

Merge branch 'jc/linkgit-fix'

Many 'linkgit:<git documentation page>' references were broken,
which are all fixed with this.

* jc/linkgit-fix:
  Documentation: fix linkgit references

Merge branch 'va/i18n-remote-comment-to-align'

Message fix.

* va/i18n-remote-comment-to-align:
  i18n: remote: add comment for translators

Merge branch 'tb/t5601-sed-fix'

Test fix.

* tb/t5601-sed-fix:
  t5601: Remove trailing space in sed expression

Merge branch 'nd/error-errno'

The code for warning_errno/die_errno has been refactored and a new
error_errno() reporting helper is introduced.

* nd/error-errno: (41 commits)
  wrapper.c: use warning_errno()
  vcs-svn: use error_errno()
  upload-pack.c: use error_errno()
  unpack-trees.c: use error_errno()
  transport-helper.c: use error_errno()
  sha1_file.c: use {error,die,warning}_errno()
  server-info.c: use error_errno()
  sequencer.c: use error_errno()
  run-command.c: use error_errno()
  rerere.c: use error_errno() and warning_errno()
  reachable.c: use error_errno()
  mailmap.c: use error_errno()
  ident.c: use warning_errno()
  http.c: use error_errno() and warning_errno()
  grep.c: use error_errno()
  gpg-interface.c: use error_errno()
  fast-import.c: use error_errno()
  entry.c: use error_errno()
  editor.c: use error_errno()
  diff-no-index.c: use error_errno()
  ...

Merge branch 'jc/test-seq'

Test fix.

* jc/test-seq:
  test-lib-functions.sh: rewrite test_seq without Perl
  test-lib-functions.sh: remove misleading comment on test_seq

Merge branch 'es/test-gpg-tags'

Test fix.

* es/test-gpg-tags:
  t6302: simplify non-gpg cases

Merge branch 'ak/t4151-ls-files-could-be-empty'

Test fix.

* ak/t4151-ls-files-could-be-empty:
  t4151: make sure argument to 'test -z' is given

Merge branch 'jk/submodule-c-credential'

An earlier addition of "sanitize_submodule_env" with 14111fc4 (git:
submodule honor -c credential.* from command line, 2016-02-29)
turned out to be a convoluted no-op; implement what it wanted to do
correctly, and stop filtering settings given via "git -c var=val".

* jk/submodule-c-credential:
  submodule: stop sanitizing config options
  submodule: use prepare_submodule_repo_env consistently
  submodule--helper: move config-sanitizing to submodule.c
  submodule: export sanitized GIT_CONFIG_PARAMETERS
  t5550: break submodule config test into multiple sub-tests
  t5550: fix typo in $HTTPD_URL

Merge branch 'nd/remote-plural-ours-plus-theirs'

Message fix.

* nd/remote-plural-ours-plus-theirs:
  remote.c: specify correct plural form in "commit diverge" message

Merge branch 'bn/config-doc-tt-varnames'

Doc formatting fixes.

* bn/config-doc-tt-varnames:
  config: consistently format $variables in monospaced font

Merge branch 'va/i18n-misc-updates'

Mark several messages for translation.

* va/i18n-misc-updates:
  i18n: unpack-trees: avoid substituting only a verb in sentences
  i18n: builtin/pull.c: split strings marked for translation
  i18n: builtin/pull.c: mark placeholders for translation
  i18n: git-parse-remote.sh: mark strings for translation
  i18n: branch: move comment for translators
  i18n: branch: unmark string for translation
  i18n: builtin/rm.c: remove a comma ',' from string
  i18n: unpack-trees: mark strings for translation
  i18n: builtin/branch.c: mark option for translation
  i18n: index-pack: use plural string instead of normal one

Merge branch 'js/t3404-typofix'

* js/t3404-typofix:
  t3404: fix typo

Merge branch 'sb/z-is-gnutar-ism'

* sb/z-is-gnutar-ism:
  t6041: do not compress backup tar file
  t3513: do not compress backup tar file

Merge branch 'lp/typofixes'

* lp/typofixes:
  typofix: assorted typofixes in comments, documentation and messages

Merge branch 'sb/submodule-deinit-all'

Correct faulty recommendation to use "git submodule deinit ." when
de-initialising all submodules, which would result in a strange
error message in a pathological corner case.

* sb/submodule-deinit-all:
  submodule deinit: require '--all' instead of '.' for all submodules

Merge branch 'jc/config-pathname-type'

Consolidate description of tilde-expansion that is done to
configuration variables that take pathname to a single place.

* jc/config-pathname-type:
  config: describe 'pathname' value type

Merge branch 'bn/http-cookiefile-config'

"http.cookieFile" configuration variable clearly wants a pathname,
but we forgot to treat it as such by e.g. applying tilde expansion.

* bn/http-cookiefile-config:
  http: expand http.cookieFile as a path
  Documentation: config: improve word ordering for http.cookieFile

Merge branch 'ab/hooks'

A new configuration variable core.hooksPath allows customizing
where the hook directory is.

* ab/hooks:
  hooks: allow customizing where the hook directory is
  githooks.txt: minor improvements to the grammar & phrasing
  githooks.txt: amend dangerous advice about 'update' hook ACL
  githooks.txt: improve the intro section

Merge branch 'sb/submodule-init'

Update of "git submodule" to move pieces of logic to C continues.

* sb/submodule-init:
  submodule init: redirect stdout to stderr
  submodule--helper update-clone: abort gracefully on missing .gitmodules
  submodule init: fail gracefully with a missing .gitmodules file
  submodule: port init from shell to C
  submodule: port resolve_relative_url from shell to C

t1500: be considerate to future potential tests

The final batch of git-rev-parse tests work against a non-local object
database named repo.git. This is done by renaming .git to repo.git and
pointing GIT_DIR at it, but the name is never restored to .git at the
end of the script, which can be problematic for tests added in the
future. Be more friendly by instead making repo.git a copy of .git.

Furthermore, make it clear that tests in repo.git will be independent
from the results of earlier tests done in .git by initializing repo.git
earlier in the test sequence.

Likewise, bundle remaining preparation (such as directory creation) into
a common setup test consistent with modern practice.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

difftool: handle unmerged files in dir-diff mode

When files are unmerged they can show up as both unmerged and
modified in the output of `git diff --raw`.  This causes
difftool's dir-diff to create filesystem entries for the same
path twice, which fails when it encounters a duplicate path.

Ensure that each worktree path is only processed once.
Add a test to demonstrate the breakage.

Reported-by: Jan Smets <jan@smets.cx>
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

difftool: initialize variables for readability

The code always goes into one of the two conditional blocks but make it
clear that not doing so is an error condition by setting $ok to 0.

Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

always quote shell arguments to test -z/-n

In shell code like:

  test -z $foo
  test -n $foo

that does not quote its arguments, it's easy to think that
it is actually looking at the contents of $foo in each case.
But if $foo is empty, then "test" does not see any argument
at all! The results are quite subtle.

POSIX specifies that test's behavior depends on the number
of arguments it sees, and if $foo is empty, it sees only
one. The behavior in this case is:

  1 argument: Exit true (0) if $1 is not null; otherwise,
              exit false.

So in the "-z $foo" case, if $foo is empty, then we check
that "-z" is non-null, and it returns success. Which happens
to match what we expected.  But for "-n $foo", if $foo is
empty, we'll see that "-n" is non-null and still return
success. That's the opposite of what we intended!

Furthermore, if $foo contains whitespace, we'll end up with
more than 2 arguments. The results in this case are
generally unspecified (unless the first part of $foo happens
to be a valid binary operator, in which case the results are
specified but certainly not what we intended).

And on top of this, even though "test -z $foo" _should_ work
for the empty case, some older shells (reportedly ksh88)
complain about the missing argument.

So let's make sure we consistently quote our variable
arguments to "test". After this patch, the results of:

  git grep 'test -[zn] [^"]'

are empty.

Reported-by: Armin Kunaschik <megabreit@googlemail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9103: modernize test style

The main goal here was to avoid double-quotes for
surrounding the test snippet, since it makes the code hard
to read (and to grep for common problems).

But while we're here, we can fix a few other things:

  - use test_path_* helpers, which are more robust and give
    better error messages

  - only "cd" inside a subshell, which leaves the
    environment pristine if further tests are added

  - consistently quote shell arguments. These aren't wrong
    if we assume find-rev output doesn't have any
    whitespace, but it doesn't hurt to be careful.

  - replace the old-style 'test x$foo = x' with 'test -z
    "$foo"'. Besides the quoting fix, this is the form we
    generally use in our test suite.

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

t9107: switch inverted single/double quotes in test

One of the test snippets in t9107 is enclosed in double
quotes, but then uses single quotes to surround an
interpolated variable inside the snippet, like:

  test_expect_success '...' "
test -n '$head'
  "

This happens to work because the variable is interpolated
_before_ the snippet is run, and the result is eval'd. So as
long as the variable does not contain any single quotes, the
two are equivalent. And it doesn't, as we know it is a sha1
from rev-parse above.  But this construct is unnecessarily
confusing.

But we can go a step further in cleaning up. The test is
really checking that a particular ref has a value. Rather
than checking if rev-parse produced output, we can just move
rev-parse into the test itself, and rely on the exit code
from --verify. Nobody else cares about the $head variable at
all.

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

t9107: use "return 1" instead of "exit 1"

When a test runs a loop, it cannot rely on the usual
&&-chaining to propagate a failure inside the loop; it needs
to break out with a failure signal. However, unless you are
in a subshell, doing so with "exit 1" will exit the entire
test script, not just the test snippet we are in (and cause
the harness to complain that test_done was never reached).

So the fundamental point of this patch is s/exit/return/.
But while we're there, let's fix a number of style and
readability issues:

  - snippets in double-quotes need an extra layer of quoting
    for their meta-characters; let's avoid that by using
    single quotes

  - accumulating loop output by appending to a file in each
    iteration is brittle, as it can be affected by content
    left in the file by earlier tests. Instead, it's better
    to redirect stdout for the whole loop, so we know the
    output only comes from that loop.

  - using "test -z" to check that diff output is empty is
    overly verbose; we can just ask diff to use --exit-code.

  - we can factor out long lists of refs to make it more
    obvious we're using the same ones in each loop

  - subshells are unnecessary when ending an &&-chain with
    "|| return 1"

  - minor style fixups like space-after-redirection, and
    "do" and "done" on their own lines

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

diff: run arguments through precompose_argv

When running diff commands, a pathspec containing decomposed
unicode code points is not converted to precomposed unicode form
under Mac OS X, but we normalize the paths in the index and the
history to precomposed form on that platform.  As a result, the
pathspec would not match and no diff is shown.

Unlike many builtin commands, the "diff" family of commands do
not use parse_options(), which is how other builtin commands
indirectly call precompose_argv() to normalize argv[] into
precomposed form on Mac OSX.  Teach these commands to call
precompose_argv() themselves.

Note that precomopose_argv() normalizes not just paths but all
command line arguments, so things like "git diff -G $string"
when $string has the decomposed form would first be normalized
into the precomposed form and would stop hitting the same string
in the decomposed form in the diff output with this change.

It is not a problem per-se, as "log" family of commands already use
parse_options() and call precompose_argv()--we can think of this
change as making the "diff" family of commands behave in a similar
way as the commands in the "log" family.

Signed-off-by: Alexander Rinass <alex@fournova.com>
Helped-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9100,t3419: enclose all test code in single-quotes

A few tests here use double-quotes around the snippets of
shell code to run the tests. None of these tests wants to do
any interpolation at all, and it just leads to an extra
layer of quoting around all double-quotes and dollar signs
inside the snippet.  Let's switch to single quotes, like
most other test scripts.

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

t/lib-git-svn: drop $remote_git_svn and $git_svn_id

These variables were added in 16805d3 (t/t91XX-svn: start
removing use of "git-" from these tests, 2008-09-08) so that
running:

  git grep git-

would return fewer hits. At the time, we were transitioning
away from the use of the "dashed" git-foo form.

That transition has been over for years, and grepping for
"git-" in the test suite yields thousands of hits anyway
(all presumably false positives).

With their original purpose gone, these variables serve only
to obfuscate the tests. Let's get rid of them.

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

Twelfth batch for 2.9

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

Merge branch 'sb/submodule-module-list-pathspec-fix'

* sb/submodule-module-list-pathspec-fix:
  submodule deinit test: fix broken && chain in subshell

Merge branch 'jc/commit-tree-ignore-commit-gpgsign'

"git commit-tree" plumbing command required the user to always sign
its result when the user sets the commit.gpgsign configuration
variable, which was an ancient mistake.  Rework "git rebase" that
relied on this mistake so that it reads commit.gpgsign and pass (or
not pass) the -S option to "git commit-tree" to keep the end-user
expectation the same, while teaching "git commit-tree" to ignore
the configuration variable.  This will stop requiring the users to
sign commit objects used internally as an implementation detail of
"git stash".

* jc/commit-tree-ignore-commit-gpgsign:
  commit-tree: do not pay attention to commit.gpgsign

git-multimail: update to release 1.3.1

The changes are described in CHANGES.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: clarify signature verification

Clarify that "merge --verify-signatures" checks the signature on the
tip commit of the history being merged.

Uniformise the vocabulary used wrt. key/signature validity with OpenPGP:
- a signature is valid if made by a key with a valid uid;
- in the default trust-model, a uid is valid if signed by a trusted key;
- a key is trusted if the (local) user set a trust level for it.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Keller Fuchs <KellerFuchs@hashbang.sh>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

perf: run "rebase -i" under perf

This developer spent a lot of time trying to speed up the interactive
rebase, in particular on Windows. And will continue to do so.

To make it easier to demonstrate the performance improvement, let's have
a reproducible performance test.

The topic branch we use to test performance was found using these shell
commands (essentially searching for a long-enough topic branch in Git's
own history that touched the same file multiple times):

git rev-list --parents origin/master |
grep ' .* ' |
while read commit rest
do
patch_count=$(git rev-list --count $commit^..$commit^2)
test $patch_count -gt 20 || continue

merges="$(git rev-list --parents $commit^..$commit^2 |
grep ' .* ')"
test -z "$merges" || continue

patches_per_file="$(git log --pretty=%H --name-only \
$commit^..$commit^2 |
grep -v '^$' |
sort |
uniq -c -d |
sort -n -r)"
test -n "$patches_per_file" &&
test 20 -lt $(echo "$patches_per_file" |
sed -n '1s/^ *\([0-9]*\).*/\1/p') || continue

printf 'commit %s\n%s\n' "$commit" "$patches_per_file"
done

Note that we can get away with *not* having to reset to the original
branch tip before rebasing: we switch the first two "pick" lines every
time, so we end up with the same patch order after two rebases, and the
complexity of both rebases is equivalent.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

perf: make the tests work in worktrees

This patch makes perf-lib.sh more robust so that it can run correctly
even inside a worktree. For example, it assumed that $GIT_DIR/objects is
the objects directory (which is not the case for worktrees) and it used
the commondir file verbatim, even if it contained a relative path.

Furthermore, the setup code expected `git rev-parse --git-dir` to spit
out a relative path, which is also not true for worktrees. Let's just
change the code to accept both relative and absolute paths, by avoiding
the `cd` into the copied working directory.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

perf: let's disable symlinks when they are not available

We already have a perfectly fine prereq to tell us whether it is safe to
use symlinks. So let's use it.

This fixes the performance tests in Git for Windows' SDK, where symlinks
are not really available ([*1*]). This is not an issue with Git for
Windows itself because it configures core.symlinks=false in its system
config.  However, the system config is disabled for the performance
tests, for obvious reasons: we want them to be independent of the
vagaries of any local configuration.

Footnote *1*: Windows has symbolic links. Git for Windows disables them
by default, though (for example: in standard setups, non-admins lack the
privilege to create symbolic links). For details, see
https://github.com/git-for-windows/git/wiki/Symbolic-Links

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: unpack-trees: avoid substituting only a verb in sentences

Instead of reusing the same set of message templates for checkout
and other actions and substituting the verb with "%s", prepare
separate message templates for each known action. That would make
it easier for translation into languages where the same verb may
conjugate differently depending on the message we are giving.

See gettext documentation for details:
http://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rerere: plug memory leaks upon "rerere forget" failure

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

Documentation/git-mailinfo: fix typo

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test-lib: set BASH_XTRACEFD automatically

Passing "-x" to a test script enables the shell's "set -x"
tracing, which can help with tracking down the command that
is causing a failure. Unfortunately, it can also _cause_
failures in some tests that redirect the stderr of a shell
function.  Inside the function the shell continues to
respect "set -x", and the trace output is collected along
with whatever stderr is generated normally by the function.

You can see an example of this by running:

  ./t0040-parse-options.sh -x -i

which will fail immediately in the first test, as it
expects:

  test_must_fail some-cmd 2>output.err

to leave output.err empty (but with "-x" it has our trace
output).

Unfortunately there isn't a portable or scalable solution to
this. We could teach test_must_fail to disable "set -x", but
that doesn't help any of the other functions or subshells.

However, we can work around it by pointing the "set -x"
output to our descriptor 4, which always points to the
original stderr of the test script. Unfortunately this only
works for bash, but it's better than nothing (and other
shells will just ignore the BASH_XTRACEFD variable).

The patch itself is a simple one-liner, but note the caveats
in the accompanying comments.

Automatic tests for our "-x" option may be a bit too meta
(and a pain, because they are bash-specific), but I did
confirm that it works correctly both with regular "-x" and
with "--verbose-only=1". This works because the latter flips
"set -x" off and on for particular tests (if it didn't, we
would get tracing for all tests, as going to descriptor 4
effectively circumvents the verbose flag).

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

Windows: only add a no-op pthread_sigmask() when needed

In f924b52 (Windows: add pthread_sigmask() that does nothing,
2016-05-01), we introduced a no-op for Windows. However, this breaks
building Git in Git for Windows' SDK because pthread_sigmask() is
already a no-op there, #define'd in the pthread_signal.h header in
/mingw64/x86_64-w64-mingw32/include/.

Let's wrap the definition of pthread_sigmask() in a guard that skips
it when compiling with MinGW-w64' headers.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: remove unnecessary definition

For some reason, the definition of the MINGW version of
`mark_as_git_dir()` slipped into this developer's patch series to
support building Git for Windows.

As the `mark_as_git_dir()` function is not needed at all anymore (it was
used originally to support the core.hideDotFiles = gitDirOnly setting,
but we now use a different method to support that case), let's just
remove it.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: introduce the 'core.hideDotFiles' setting

On Unix (and Linux), files and directories whose names start with a dot
are usually not shown by default. This convention is used by Git: the
.git/ directory should be left alone by regular users, and only accessed
through Git itself.

On Windows, no such convention exists. Instead, there is an explicit flag
to mark files or directories as hidden.

In the early days, Git for Windows did not mark the .git/ directory (or
for that matter, any file or directory whose name starts with a dot)
hidden. This lead to quite a bit of confusion, and even loss of data.

Consequently, Git for Windows introduced the core.hideDotFiles setting,
with three possible values: true, false, and dotGitOnly, defaulting to
marking only the .git/ directory as hidden.

The rationale: users do not need to access .git/ directly, and indeed (as
was demonstrated) should not really see that directory, either. However,
not all dot files should be hidden by default, as e.g. Eclipse does not
show them (and the user would therefore be unable to see, say, a
.gitattributes file).

In over five years since the last attempt to bring this patch into core
Git, a slightly buggy version of this patch has served Git for Windows'
users well: no single report indicated problems with the hidden .git/
directory, and the stream of problems caused by the previously non-hidden
.git/ directory simply stopped. The bugs have been fixed during the
process of getting this patch upstream.

Note that there is a funny quirk we have to pay attention to when
creating hidden files: we use Win32's _wopen() function which
transmogrifies its arguments and hands off to Win32's CreateFile()
function. That latter function errors out with ERROR_ACCESS_DENIED (the
equivalent of EACCES) when the equivalent of the O_CREAT flag was passed
and the file attributes (including the hidden flag) do not match an
existing file's. And _wopen() accepts no parameter that would be
transmogrified into said hidden flag. Therefore, we simply try again
without O_CREAT.

A slightly different method is required for our fopen()/freopen()
function as we cannot even *remove* the implicit O_CREAT flag.
Therefore, we briefly mark existing files as unhidden when opening them
via fopen()/freopen().

The ERROR_ACCESS_DENIED error can also be triggered by opening a file
that is marked as a system file (which is unlikely to be tracked in
Git), and by trying to create a file that has *just* been deleted and is
awaiting the last open handles to be released (which would be handled
better by the "Try again?" logic, a story for a different patch series,
though). In both cases, it does not matter much if we try again without
the O_CREAT flag, read: it does not hurt, either.

For details how ERROR_ACCESS_DENIED can be triggered, see
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858

Original-patch-by: Erik Faye-Lund <kusmabite@gmail.com>
Initial-Test-By: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase--interactive: avoid empty list in shell for-loop

The $strategy_opts variable contains a space-separated list
of strategy options, each individually shell-quoted. To loop
over each, we "unwrap" them by doing an eval like:

  eval '
    for opt in '"$strategy_opts"'
    do
       ...
    done
  '

Note the quoting that means we expand $strategy_opts inline
in the code to be evaluated (which is the right thing
because we want the IFS-split and de-quoting). If the
variable is empty, however, we ask the shell to eval the
following code:

  for opt in
  do
     ...
  done

without anything between "in" and "do".  Most modern shells
are happy to treat that like a noop, but reportedly ksh88 on
AIX considers it a syntax error. So let's catch the case
that the variable is empty and skip the eval altogether
(since we know the loop would be a noop anyway).

Reported-by: Armin Kunaschik <megabreit@googlemail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Eleventh batch for 2.9

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

Merge branch 'svn/bad-ref' of git://bogomips.org/git-svn

* 'svn/bad-ref' of git://bogomips.org/git-svn:
  Git/SVN: die when there is no commit metadata

Merge branch 'sk/gitweb-highlight-encoding'

Some multi-byte encoding can have a backslash byte as a later part
of one letter, which would confuse "highlight" filter used in
gitweb.

* sk/gitweb-highlight-encoding:
  gitweb: apply fallback encoding before highlight

Merge branch 'sb/clean-test-fix'

* sb/clean-test-fix:
  t7300: mark test with SANITY

Merge branch 'rn/glossary-typofix'

* rn/glossary-typofix:
  Documentation: fix typo 'In such these cases'

Merge branch 'ls/travis-submitting-patches'

* ls/travis-submitting-patches:
  Documentation: add setup instructions for Travis CI

Merge branch 'js/close-packs-before-gc'

* js/close-packs-before-gc:
  t5510: run auto-gc in the foreground

Merge branch 'ew/normal-to-e'

* ew/normal-to-e:
  .mailmap: update to my shorter email address

Merge branch 'ls/p4-lfs'

Recent update to Git LFS broke "git p4" by changing the output from
its "lfs pointer" subcommand.

* ls/p4-lfs:
  git-p4: fix Git LFS pointer parsing
  travis-ci: express Linux/OS X dependency versions more clearly
  travis-ci: update Git-LFS and P4 to the latest version

Merge branch 'sb/misc-cleanups'

* sb/misc-cleanups:
  submodule-config: don't shadow `cache`
  config.c: drop local variable

Merge branch 'ew/doc-split-pack-disables-bitmap'

Doc update.

* ew/doc-split-pack-disables-bitmap:
  pack-objects: warn on split packs disabling bitmaps

wrap-for-bin.sh: regenerate bin-wrappers when switching branches

Commit e6e7530 (test helpers: move test-* to t/helper/ subdirectory -
2016-04-13) moves test-* to t/helper. However because bin-wrappers/*
only depend on wrap-for-bin.sh, when switching between a branch that has
this commit and one that does not, bin-wrappers/* may not be regenerated
and point to the old/outdated test programs.

This commit makes a non-functional change in wrap-for-bin.sh, just
enough for 'make' to detect and re-execute wrap-for-bin.sh. When
switching between a branch containing both this commit and e6e7530 and
one containing neither, bin-wrappers/*, we should get fresh bin-wrappers/*.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0040: convert a few tests to use test-parse-options --expect

As a small example of using "test-parse-options --expect",
rewrite the "check" helper using it, instead of comparing
the whole variable dump.

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

t0040: remove unused test helpers

9a001381 (Fix tests under GETTEXT_POISON on parseopt, 2012-08-27)
introduced check_i18n, but the helper was never used from the
beginning.

The same commit also introduced check_unknown_i18n to replace the
helper check_unknown and changed all users of the latter to use the
former, but failed to remove check_unknown itself.

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

test-parse-options: --expect=<string> option to simplify tests

Existing tests in t0040 follow a rather verbose pattern:

        cat >expect <<\EOF
        boolean: 0
        integer: 0
        magnitude: 0
        timestamp: 0
        string: (not set)
        abbrev: 7
        verbose: 0
        quiet: 3
        dry run: no
        file: (not set)
        EOF

        test_expect_success 'multiple quiet levels' '
                test-parse-options -q -q -q >output 2>output.err &&
                test_must_be_empty output.err &&
                test_cmp expect output
        '

But the only thing this test cares about is if "quiet: 3" is in the
output.  We should be able to write the above 18 lines with just
four lines, like this:

test_expect_success 'multiple quiet levels' '
test-parse-options --expect="quiet: 3" -q -q -q
'

Teach the new --expect=<string> option to test-parse-options helper.

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

test-parse-options: fix output when callback option fails

When test-parse-options detects an error on the command line, it
gives the usage string just like any parse-options API users do,
without showing any "variable dump".  An exception is the callback
test, where a "variable dump" for the option is done before the
command line options are fully parsed.

Do not expose this implementation detail by separating the handling
of callback test into two phases, one to capture the fact that an
option was given during the option parsing phase, and the other to
show that fact as a part of normal "variable dump".

The effect of this fix is seen in the patch to t/t0040 where it
tried "test-parse-options --no-length" where "--length" is a callback
that does not take a negative form.

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

submodule: ensure that -c http.extraheader is heeded

To support this developer's use case of allowing build agents token-based
access to private repositories, we introduced the http.extraheader
feature, allowing extra HTTP headers to be sent along with every HTTP
request.

This patch verifies that we can configure these extra HTTP headers via the
command-line for use with `git submodule update`, too. Example: git -c
http.extraheader="Secret: Sauce" submodule update --init

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3404: fix typo

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

travis-ci: build documentation

Build documentation as separate Travis CI job to check for
documentation errors.

Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ci: validate "linkgit:" in documentation

It is easy to add incorrect "linkgit:<page>[<section>]" references
to our documentation suite.  Catch these common classes of errors:

 * Referring to Documentation/<page>.txt that does not exist.

 * Referring to a <page> outside the Git suite.  In general, <page>
   must begin with "git".

 * Listing the manual <section> incorrectly.  The first line of the
   Documentation/<page>.txt must end with "(<section>)".

with a new script "ci/lint-gitlink", and drive it from "make check-docs".

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

Merge branch 'jk/submodule-c-credential' into js/http-custom-headers

* jk/submodule-c-credential:
  submodule: stop sanitizing config options
  submodule: use prepare_submodule_repo_env consistently
  submodule--helper: move config-sanitizing to submodule.c
  submodule: export sanitized GIT_CONFIG_PARAMETERS
  t5550: break submodule config test into multiple sub-tests
  t5550: fix typo in $HTTPD_URL
  git_config_push_parameter: handle empty GIT_CONFIG_PARAMETERS
  git: submodule honor -c credential.* from command line
  quote: implement sq_quotef()
  submodule: fix segmentation fault in submodule--helper clone
  submodule: fix submodule--helper clone usage
  submodule: check argc count for git submodule--helper clone
  submodule: don't pass empty string arguments to submodule--helper clone

t5551: make the test for extra HTTP headers more robust

To test that extra HTTP headers are passed correctly, t5551 verifies that
a fetch succeeds when two required headers are passed, and that the fetch
does not succeed when those headers are not passed.

However, this test would also succeed if the configuration required only
one header. As Apache's configuration is notoriously tricky (this
developer frequently requires StackOverflow's help to understand Apache's
documentation), especially when still supporting the 2.2 line, let's just
really make sure that the test verifies what we want it to verify.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: adjust the configuration for Apache 2.2

Lars Schneider noticed that the configuration introduced to test the
extra HTTP headers cannot be used with Apache 2.2 (which is still
actively maintained, as pointed out by Junio Hamano).

To let the tests pass with Apache 2.2 again, let's substitute the
offending <RequireAll> and `expr` by using old school RewriteCond
statements.

As RewriteCond does not allow testing for *non*-matches, we simply match
the desired case first and let it pass by marking the RewriteRule as
'[L]' ("last rule, do not process any other matching RewriteRules after
this"), and then have another RewriteRule that matches all other cases
and lets them fail via '[F]' ("fail").

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit: add a commit.verbose config variable

Add commit.verbose configuration variable as a convenience for those
who always prefer --verbose.

Add tests to check the behavior introduced by this commit and also to
verify that behavior of status doesn't break because of this commit.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fsck: detect and warn a commit with embedded NUL

Even though a Git commit object is designed to be capable of storing
any binary data as its payload, in practice people use it to describe
the changes in textual form, and tools like "git log" are designed to
treat the payload as text.

Detect and warn when we see any commit object with a NUL byte in
it.

Note that a NUL byte in the header part is already detected as a
grave error.  This change is purely about the message part.

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

Documentation: fix linkgit references

There are a handful of incorrect "linkgit:<page>[<section>]"
instances in our documentation set.

 * Some have an extra colon after "linkgit:"; fix them by removing
   the extra colon;

 * Some refer to a page outside the Git suite, namely curl(1); fix
   them by using the `curl(1)` that already appears on the same page
   for the same purpose of referring the readers to its manual page.

 * Some spell the name of the page incorrectly, e.g. "rev-list" when
   they mean "git-rev-list"; fix them.

 * Some list the manual section incorrectly; fix them to make sure
   they match what is at the top of the target of the link.

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

t6036: remove pointless test that expects failure

One test in t6036 prepares a file whose contents contain these
lines:

<<<<<<< Temporary merge branch 1
C
=======
B
>>>>>>> Temporary merge branch 2

and uses recursive merge strategy to run criss-cross merge with it.

Manual merge resolution by users fundamentally depends on being able
to distinguish the tracked contents from the separator lines added
by "git merge" in order to allow users to tell which block of lines
came from where.  You can deliberately craft a file with lines that
resemble conflict marker lines to make it impossible for the user
(the outer merge of merge-recursive counts as a user of the result
of "virtual parent" merge) to tell which part is which, and write a
test to demonstrate that with such a file that "git merge" cannot
fundamentally work well and has to fail.

It however is pointless and waste of time and resource to run such a
test that asserts the obvious.

In real life, people who do need to track files with such lines that
have <<<< ==== >>>> as their prefixes set the conflict-marker-size
attribute to make sure they will be able to tell between the tracked
lines that happen to begin with these (confusing) prefixes and the
marker lines that are added by "git merge".

Remove the test as pointless waste of resource.

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

ll-merge: use a longer conflict marker for internal merge

The primary use of conflict markers is to help the user who resolves
the final (outer) merge by hand to show which part came from which
branch by separating the blocks of lines apart.  When the conflicted
parts from a "virtual ancestor" merge created by merge-recursive
remains in the common ancestor part in the final result, however,
the conflict markers that are the same size as the final merge
become harder to see.

Increase the conflict marker size slightly for these inner merges so
that the markers from the final merge and cruft from internal merge
can be distinguished more easily.

This would help reduce the common issue that prevents "rerere" from
being used on a really complex conflict.

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

test-lib-functions.sh: rewrite test_seq without Perl

Rewrite the 'seq' imitation using only commands and features that
are typically found built into modern POSIX shells, instead of
relying on Perl to run a single-liner script.

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

t4151: make sure argument to 'test -z' is given

88d50724 (am --skip: revert changes introduced by failed 3way merge,
2015-06-06), unlike all the other patches in the series, forgot to
quote the output from "$(git ls-files -u)" when using it as the
argument to "test -z", leading to a syntax error on platforms whose
test does not interpret "test -z" (no other arguments) as testing if
a string "-z" is the null string (which GNU test and test that is
built into bash and dash seem to do).

Note that $(git ls-files -u | wc -l) is deliberately left unquoted,
as some implementations of "wc -l" includes extra blank characters
in its output and cannot be compared as string, i.e. "test 0 = $(...)".

Signed-off-by: Armin Kunaschik <megabreit@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test-lib-functions.sh: remove misleading comment on test_seq

We never used the "letters" form since we came up with "test_seq" to
replace use of non-portable "seq" in our test script, which we
introduced it at d17cf5f3 (tests: Introduce test_seq, 2012-08-04).

We use this helper to either iterate for N times (i.e. the values on
the lines do not even matter), or just to get N distinct strings
(i.e. the values on the lines themselves do not really matter, but
we care that they are different from each other and reproducible).

Stop promising that we may allow using "letters"; this would open an
easier reimplementation that does not rely on $PERL, if somebody
later wants to.

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