Merge branch 'en/remove-stripspace'

An internal function that was left for backward compatibility has
been removed, as there is no remaining callers.

* en/remove-stripspace:
  strbuf: remove unused stripspace function alias

Merge branch 'jk/no-optional-locks'

Doc update for a feature available in Git v2.14 and upwards.

* jk/no-optional-locks:
  git-status.txt: mention --no-optional-locks

Merge branch 'ds/for-each-file-in-obj-micro-optim'

The code to iterate over loose object files got optimized.

* ds/for-each-file-in-obj-micro-optim:
  sha1_file: use strbuf_add() instead of strbuf_addf()

Merge branch 'jk/progress-delay-fix'

A regression in the progress eye-candy was fixed.

* jk/progress-delay-fix:
  progress: drop delay-threshold code
  progress: set default delay threshold to 100%, not 0%

Merge branch 'ks/doc-checkout-previous'

@{-N} in "git checkout @{-N}" may refer to a detached HEAD state,
but the documentation was not clear about it, which has been fixed.

* ks/doc-checkout-previous:
  Doc/checkout: checking out using @{-N} can lead to detached state

Merge branch 'fk/sendmail-from-path'

"git send-email" tries to see if the sendmail program is available
in /usr/lib and /usr/sbin; extend the list of locations to be
checked to also include directories on $PATH.

* fk/sendmail-from-path:
  git-send-email: honor $PATH for sendmail binary

Merge branch 'tg/t-readme-updates'

Developer doc updates.

* tg/t-readme-updates:
  t/README: document test_cmp_rev
  t/README: remove mention of adding copyright notices

Merge branch 'pc/submodule-helper'

A message fix.

* pc/submodule-helper:
  submodule--helper.c: i18n: add a missing space in message

Merge branch 'jc/receive-pack-hook-doc'

Doc update.

* jc/receive-pack-hook-doc:
  hooks doc: clarify when receive-pack invokes its hooks

Merge branch 'ab/pcre2-grep'

"git grep" compiled with libpcre2 sometimes triggered a segfault,
which is being fixed.

* ab/pcre2-grep:
  grep: fix segfault under -P + PCRE2 <=10.30 + (*NO_JIT)
  test-lib: add LIBPCRE1 & LIBPCRE2 prerequisites

Merge branch 'ra/decorate-limit-refs'

The tagnames "git log --decorate" uses to annotate the commits can
now be limited to subset of available refs with the two additional
options, --decorate-refs[-exclude]=<pattern>.

* ra/decorate-limit-refs:
  log: add option to choose which refs to decorate

Merge branch 'bc/hash-algo'

An infrastructure to define what hash function is used in Git is
introduced, and an effort to plumb that throughout various
codepaths has been started.

* bc/hash-algo:
  repository: fix a sparse 'using integer as NULL pointer' warning
  Switch empty tree and blob lookups to use hash abstraction
  Integrate hash algorithm support with repo setup
  Add structure representing hash algorithm
  setup: expose enumerated repo info

path: document path functions

Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

transport: remove unused "push" in vtable

After commit 0d0bac67ce3b ("transport: drop support for git-over-rsync",
2016-02-01), no transport in Git populates the "push" entry in the
transport vtable. Remove this entry.

Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

install-doc-quick: allow specifying what ref to install

We allow the builders, who want to install the preformatted manpages
and html documents, to specify where in their filesystem these two
repositories are stored.  Let them also specify which ref (or even a
revision) to grab the preformatted material from.

Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/helper: ignore everything but sources

Compiled test helpers in t/helper are out of sync with the .gitignore
files quite frequently. This can happen when new test helpers are added,
but the explicit .gitignore file is not updated in the same commit, or
when you forget to 'make clean' before checking out a different version
of git, as the different version may have a different explicit list of
test helpers to ignore.

Fix this by having an overly broad ignore pattern in that directory:
Anything, except C and shell source, will be ignored.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

travis-ci: use 'set -x' in 'ci/*' scripts for extra tracing output

While the build logic was embedded in our '.travis.yml', Travis CI
used to produce a nice trace log including all commands executed in
those embedded scriptlets.  Since 657343a60 (travis-ci: move Travis CI
code into dedicated scripts, 2017-09-10), however, we only see the
name of the dedicated scripts, but not what those scripts are actually
doing, resulting in a less useful trace log.  A patch later in this
series will move setting environment variables from '.travis.yml' to
the 'ci/*' scripts, so not even those will be included in the trace
log.

Use 'set -x' in 'ci/lib-travisci.sh', which is sourced in most other
'ci/*' scripts, so we get trace log about the commands executed in all
of those scripts.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

travis-ci: set GIT_TEST_HTTPD in 'ci/lib-travisci.sh'

Commit 657343a60 (travis-ci: move Travis CI code into dedicated
scripts, 2017-09-10) converted '.travis.yml's default 'before_install'
scriptlet to the 'ci/install-dependencies.sh' script, and while doing
so moved setting GIT_TEST_HTTPD=YesPlease for the 64-bit GCC and Clang
Linux build jobs to that script.  This is wrong for two reasons:

 - The purpose of that script is, as its name suggests, to install
   dependencies, not to set any environment variables influencing
   which tests should be run (though, arguably, this was already an
   issue with the original 'before_install' scriptlet).

 - Setting the variable has no effect anymore, because that script is
   run in a separate shell process, and the variable won't be visible
   in any of the other scripts, notably in 'ci/run-tests.sh'
   responsible for, well, running the tests.

Luckily, this didn't have a negative effect on our Travis CI build
jobs, because GIT_TEST_HTTPD is a tri-state variable defaulting to
"auto" and a functioning web server was installed in those Linux build
jobs, so the httpd tests were run anyway.

Apparently the httpd tests run just fine without GIT_TEST_HTTPD being
set, therefore we could simply remove this environment variable.
However, if a bug were to creep in to change the Travis CI build
environment to run the tests as root or to not install Apache, then
the httpd tests would be skipped and the build job would still
succeed.  We would only notice if someone actually were to look
through the build job's trace log; but who would look at the trace log
of a successful build job?!

Since httpd tests are important, we do want to run them and we want to
be loudly reminded if they can't be run.  Therefore, move setting
GIT_TEST_HTTPD=YesPlease for the 64-bit GCC and Clang Linux build jobs
to 'ci/lib-travisci.sh' to ensure that the build job fails when the
httpd tests can't be run.  (We could set it in 'ci/run-tests.sh' just
as well, but it's better to keep all environment variables in one
place in 'ci/lib-travisci.sh'.)

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

travis-ci: move setting environment variables to 'ci/lib-travisci.sh'

Our '.travis.yml's 'env.global' section sets a bunch of environment
variables for all build jobs, though none of them actually affects all
build jobs.  It's convenient for us, and in most cases it works just
fine, because irrelevant environment variables are simply ignored.

However, $GIT_SKIP_TESTS is an exception: it tells the test harness to
skip the two test scripts that are prone to occasional failures on
OSX, but as it's set for all build jobs those tests are not run in any
of the build jobs that are capable to run them reliably, either.

Therefore $GIT_SKIP_TESTS should only be set in the OSX build jobs,
but those build jobs are included in the build matrix implicitly (i.e.
by combining the matrix keys 'os' and 'compiler'), and there is no way
to set an environment variable only for a subset of those implicit
build jobs.  (Unless we were to add new scriptlets to '.travis.yml',
which is exactly the opposite direction that we took with commit
657343a60 (travis-ci: move Travis CI code into dedicated scripts,
2017-09-10)).

So move setting $GIT_SKIP_TESTS to 'ci/lib-travisci.sh', where it can
trivially be set only for the OSX build jobs.

Furthermore, move setting all other environment variables from
'.travis.yml' to 'ci/lib-travisci.sh', too, because a couple of
environment variables are already set there, and this way all
environment variables will be set in the same place.  All the logic
controlling our builds is already in the 'ci/*' scripts anyway, so
there is really no good reason to keep the environment variables
separately.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

travis-ci: introduce a $jobname variable for 'ci/*' scripts

A couple of 'ci/*' scripts are shared between different build jobs:
'ci/lib-travisci.sh', being a common library, is sourced from almost
every script, while 'ci/install-dependencies.sh', 'ci/run-build.sh'
and 'ci/run-tests.sh' are shared between the "regular" GCC and Clang
Linux and OSX build jobs, and the latter two scripts are used in the
GETTEXT_POISON Linux build job as well.

Our builds could benefit from these shared scripts being able to
easily tell which build job they are taking part in.  Now, it's
already quite easy to tell apart Linux vs OSX and GCC vs Clang build
jobs, but it gets trickier with all the additional Linux-based build
jobs included explicitly in the build matrix.

Unfortunately, Travis CI doesn't provide much help in this regard.
The closest we've got is the $TRAVIS_JOB_NUMBER variable, the value of
which is two dot-separated integers, where the second integer
indicates a particular build job.  While it would be possible to use
that second number to identify the build job in our shared scripts, it
doesn't seem like a good idea to rely on that:

  - Though the build job numbering sequence seems to be stable so far,
    Travis CI's documentation doesn't explicitly states that it is
    indeed stable and will remain so in the future.  And even if it
    were stable,

  - if we were to remove or insert a build job in the middle, then the
    job numbers of all subsequent build jobs would change accordingly.

So roll our own means of simple build job identification and introduce
the $jobname environment variable in our builds, setting it in the
environments of the explicitly included jobs in '.travis.yml', while
constructing one in 'ci/lib-travisci.sh' as the combination of the OS
and compiler name for the GCC and Clang Linux and OSX build jobs.  Use
$jobname instead of $TRAVIS_OS_NAME in scripts taking different
actions based on the OS and build job (when installing P4 and Git LFS
dependencies and including them in $PATH).  The following two patches
will also rely on $jobname.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodule: convert get_next_submodule to not rely on the_index

Instead of implicitly relying on the global 'the_index', convert
'get_next_submodule()' to use the index of the repository stored in the
callback data 'struct submodule_parallel_fetch'.

Since this removes the last user of the index compatibility macros,
define 'NO_THE_INDEX_COMPATIBILITY_MACROS' to prevent future users of
these macros in submodule.c.

Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodule: used correct index in is_staging_gitmodules_ok

Commit 883e248b8 (fsmonitor: teach git to optionally utilize a file
system monitor to speed up detecting new or changed files., 2017-09-22)
introduced a call to 'ce_match_stat()' in 'is_staging_gitmodules_ok()'
which implicitly relys on the the global 'the_index' instead of the
passed in 'struct index_state'.  Fix this by changing the call to
'ie_match_stat()' and using the passed in index_state struct.

Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodule: convert stage_updated_gitmodules to take a struct index_state

Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t: add tests for pull --verify-signatures

Add tests for pull --verify-signatures with untrusted, bad and no
signatures.  Previously the only test for --verify-signatures was to
make sure that pull --rebase --verify-signatures result in a warning
(t5520-pull.sh).

Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge: add config option for verifySignatures

git merge --verify-signatures can be used to verify that the tip commit
of the branch being merged in is properly signed, but it's cumbersome to
have to specify that every time.

Add a configuration option that enables this behaviour by default, which
can be overridden by --no-verify-signatures.

Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

format: create docs for pretty.h

Write some docs for functions in pretty.h.
Take it as a first draft, they would be changed later.

Signed-off-by: Olga Telezhnaia <olyatelezhnaya@gmail.com>
Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

format: create pretty.h file

Create header for pretty.c to make formatting interface more structured.
This is a middle point, this file would be merged further with other
files which contain formatting stuff.

Signed-off-by: Olga Telezhnaia <olyatelezhnaya@gmail.com>
Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t4045: reindent to make helpers readable

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

diff: add tests for --relative without optional prefix value

We already have tests for --relative, but they currently only test when
a prefix has been provided. This fails to test the case where --relative
by itself should use the current directory as the prefix.

Teach the check_$type functions to take a directory argument to indicate
which subdirectory to run the git commands in. Add a new test which uses
this to test --relative without a prefix value.

Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: use skip_to_optional_arg_default() in parsing --relative

Helped-by: Jacob Keller <jacob.keller@gmail.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: use skip_to_optional_arg_default()

Let's simplify diff option parsing using
skip_to_optional_arg_default().

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

diff: use skip_to_optional_arg()

Let's simplify diff option parsing using skip_to_optional_arg().

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

index-pack: use skip_to_optional_arg()

Let's simplify index-pack option parsing using
skip_to_optional_arg().

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

git-compat-util: introduce skip_to_optional_arg()

We often accept both a "--key" option and a "--key=<val>" option.

These options currently are parsed using something like:

if (!strcmp(arg, "--key")) {
/* do something */
} else if (skip_prefix(arg, "--key=", &arg)) {
/* do something with arg */
}

which is a bit cumbersome compared to just:

if (skip_to_optional_arg(arg, "--key", &arg)) {
/* do something with arg */
}

This also introduces skip_to_optional_arg_default() for the few
cases where something different should be done when the first
argument is exactly "--key" than when it is exactly "--key=".

In general it is better for UI consistency and simplicity if
"--key" and "--key=" do the same thing though, so that using
skip_to_optional_arg() should be encouraged compared to
skip_to_optional_arg_default().

Note that these functions can be used to parse any "key=value"
string where "key" is also considered as valid, not just
command line options.

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

clone: support 'clone --shared' from a worktree

When worktree functionality was originally implemented, the possibility
of 'clone --local' from within a worktree was overlooked, with the
result that the location of the "objects" directory of the source
repository was computed incorrectly, thus the objects could not be
copied or hard-linked by the clone. This shortcoming was addressed by
744e469755 (clone: allow --local from a linked checkout, 2015-09-28).

However, the related case of 'clone --shared' (despite being handled
only a few lines away from the 'clone --local' case) was not fixed by
744e469755, with a similar result of the "objects" directory location
being incorrectly computed for insertion into the 'alternates' file.
Fix this.

Reported-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

transport-helper: plug strbuf and string_list leaks

Transfer ownership of detached strbufs to string_lists of the
duplicating variety by calling string_list_append_nodup() instead of
string_list_append() to avoid duplicating and then leaking the buffer.

While at it make sure to release the string_list when done;
push_refs_with_export() already does that.

Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0027: Adapt the new MIX tests to Windows

The new MIX tests don't pass under Windows, adapt them
to use the correct native line ending.

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

doc: reword gitworkflows.txt for neutrality

Change 'he' to 'them' to be more neutral in "gitworkflows.txt".

Signed-off-by: Matthieu Moy <matthieu.moy@univ-lyon1.fr>
Signed-off-by: Timothee Albertin <timothee.albertin@etu.univ-lyon1.fr>
Signed-off-by: Nathan Payre <nathan.payre@etu.univ-lyon1.fr>
Signed-off-by: Daniel Bensoussan <daniel.bensoussan--bohm@etu.univ-lyon1.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

decorate: clean up and document API

Improve the names of the identifiers in decorate.h, document them, and
add an example of how to use these functions.

The example is compiled and run as part of the test suite.

Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/Makefile: introduce TEST_SHELL_PATH

You may want to run the test suite with a different shell
than you use to build Git. For instance, you may build with
SHELL_PATH=/bin/sh (because it's faster, or it's what you
expect to exist on systems where the build will be used) but
want to run the test suite with bash (e.g., since that
allows using "-x" reliably across the whole test suite).
There's currently no good way to do this.

You might think that doing two separate make invocations,
like:

  make &&
  make -C t SHELL_PATH=/bin/bash

would work. And it _almost_ does. The second make will see
our bash SHELL_PATH, and we'll use that to run the
individual test scripts (or tell prove to use it to do so).
So far so good.

But this breaks down when "--tee" or "--verbose-log" is
used. Those options cause the test script to actually
re-exec itself using $SHELL_PATH. But wait, wouldn't our
second make invocation have set SHELL_PATH correctly in the
environment?

Yes, but test-lib.sh sources GIT-BUILD-OPTIONS, which we
built during the first "make". And that overrides the
environment, giving us the original SHELL_PATH again.

Let's introduce a new variable that lets you specify a
specific shell to be run for the test scripts. Note that we
have to touch both the main and t/ Makefiles, since we have
to record it in GIT-BUILD-OPTIONS in one, and use it in the
latter.

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

test-lib: make "-x" work with "--verbose-log"

The "-x" tracing option implies "--verbose". This is a
problem when running under a TAP harness like "prove", where
we need to use "--verbose-log" instead. Instead, let's
handle this the same way we do for --valgrind, including the
recent fix from 88c6e9d31c (test-lib: --valgrind should not
override --verbose-log, 2017-09-05). Namely, let's enable
--verbose only when we know there isn't a more specific
verbosity option indicated.

Note that we also have to tweak `want_trace` to turn it on
(previously we just lumped $verbose_log in with $verbose,
but now we don't necessarily auto-set the latter).

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

t5615: avoid re-using descriptor 4

File descriptors 3 and 4 are special in our test suite, as
they link back to the test script's original stdout and
stderr. Normally this isn't something tests need to worry
about: they are free to clobber these descriptors for
sub-commands without affecting the overall script.

But there's one very special thing about descriptor 4: since
d88785e424 (test-lib: set BASH_XTRACEFD automatically,
2016-05-11), we ask bash to output "set -x" output to it by
number. This goes to _any_ descriptor 4, even if it no
longer points to the place it did when we set BASH_XTRACEFD.

But in t5615, we run a shell loop with descriptor 4
redirected.  As a result, t5615 works with non-bash shells
even with "-x". And it works with bash without "-x". But the
combination of "bash t5615-alternate-env.sh -x" gets a test
failure (because our "set -x" output pollutes one of the
files).

We can fix this by using any descriptor _except_ the magical
4. So let's switch arbitrarily to using 5/6 in this loop,
not 3/4.

Another alternative is to use a different descriptor for
BASH_XTRACEFD. But picking an unused one turns out to be
hard. Most shells limit us to 9 numbered descriptors. Bash
can handle more, but:

  - while the BASH_XTRACEFD is specific to bash, GIT_TRACE=4
    has a similar problem, and would affect all shells

  - constructs like "999>/dev/null" are synticatically
    invalid to non-bash shells. So we have to actually bury
    it inside an eval, which creates more complications.

Of the numbers 1-9, you might think that "9" would be less
used than "4". But it's not; many of our scripts use
descriptors 8 and 9 (probably under the assumption that they
are high and therefore unused). The least-used descriptor is
currently "7". We could switch to that, but we're just
trading one magic number for another.

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

test-lib: silence "-x" cleanup under bash

When the test suite's "-x" option is used with bash, we end
up seeing cleanup cruft in the output:

  $ bash t0001-init.sh -x
  [...]
  ++ diff -u expected actual
  + test_eval_ret_=0
  + want_trace
  + test t = t
  + test t = t
  + set +x
  ok 42 - re-init from a linked worktree

This ranges from mildly annoying (for a successful test) to
downright confusing (when we say "last command exited with
error", but it's really 5 commands back).

We normally are able to suppress this cleanup. As the
in-code comment explains, we can't convince the shell not to
print it, but we can redirect its stderr elsewhere.

But since d88785e424 (test-lib: set BASH_XTRACEFD
automatically, 2016-05-11), that doesn't hold for bash. It
sends the "set -x" output directly to descriptor 4, not to
stderr.

We can fix this by also redirecting descriptor 4, and
paying close attention to which commands redirected and
which are not (see the updated comment).

Two alternatives I considered and rejected:

  - unsetting and setting BASH_XTRACEFD; doing so closes the
    descriptor, which we must avoid

  - we could keep everything in a single block as before,
    redirect 4>/dev/null there, but retain 5>&4 as a copy.
    And then selectively restore 4>&5 for commands which
    should be allowed to trace. This would work, but the
    descriptor swapping seems unnecessarily confusing.

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

cvsimport: apply shell-quoting regex globally

Commit 5b4efea666 (cvsimport: shell-quote variable used in
backticks, 2017-09-11) tried to shell-quote a variable, but
forgot to use the "/g" modifier to apply the quoting to the
whole variable. This means we'd miss any embedded
single-quotes after the first one.

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

docs/pretty-formats: mention commas in %(trailers) syntax

Commit 84ff053d47 (pretty.c: delimit "%(trailers)" arguments
with ",", 2017-10-01) switched the syntax of the trailers
placeholder, but forgot to update the documentation in
pretty-formats.txt.

There's no need to mention the old syntax; it was never in a
released version of Git.

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

builtin/branch: strip refs/heads/ using skip_prefix

Instead of hard-coding the offset strlen("refs/heads/") to skip
the prefix "refs/heads/" use the skip_prefix() function which
is more communicative and verifies that the string actually
starts with that prefix.

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

branch: update warning message shown when copying a misnamed branch

When a user tries to rename a branch that has a "bad name" (e.g.,
starts with a '-') then we warn them that the misnamed branch has
been renamed "away". A similar message is shown when trying to create
a copy of a misnamed branch even though it doesn't remove the misnamed
branch. This is not correct and may confuse the user.

So, update the warning message shown to be more precise that only a copy
of the misnamed branch has been created. It's better to show the warning
message than not showing it at all as it makes the user aware of the
presence of a misnamed branch.

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

branch: group related arguments of create_branch()

39bd6f726 (Allow checkout -B <current-branch> to update the current
branch, 2011-11-26) added 'clobber_head' (now, 'clobber_head_ok')
"before" 'track' as 'track' was closely related 'clobber_head' for
the purpose the commit wanted to achieve. Looking from the perspective
of how the arguments are used it turns out that 'clobber_head' is
more related to 'force' than it is to 'track'.

So, re-order the arguments to keep the related arguments close
to each other.

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

branch: improve documentation and naming of create_branch() parameters

The documentation for 'create_branch()' was incomplete as it didn't say
what certain parameters were used for. Further a parameter name wasn't
very communicative.

So, add missing documentation for the sake of completeness and easy
reference. Also, rename the concerned parameter to make its name more
communicative.

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

worktree: invoke post-checkout hook (unless --no-checkout)

git-clone and git-checkout both invoke the post-checkout hook following
a successful checkout, yet git-worktree neglects to do so even though it
too "checks out" the worktree. Fix this oversight.

Implementation note: The newly-created worktree may reference a branch
or be detached. In the latter case, a commit lookup is performed, though
the result is used only in a boolean sense to (a) determine if the
commit actually exists, and (b) assign either the branch name or commit
ID to HEAD. Since the post-commit hook needs to know the ID of the
checked-out commit, the lookup now needs to be done in all cases, rather
than only when detached. Consequently, a new boolean is needed to handle
(b) since the lookup result itself can no longer perform that role.

Reported-by: Matthew K Gumbel <matthew.k.gumbel@intel.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

strbuf: release memory on read error in strbuf_read_once()

If other strbuf add functions cause the first allocation and
subsequently encounter an error then they release the memory, restoring
the pristine state of the strbuf.  That simplifies error handling for
callers.

Do the same in strbuf_read_once(), and do it also in case no bytes were
read -- which may or may not be an error as well, depending on the
caller.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fmt-merge-msg: avoid leaking strbuf in shortlog()

Use string_list_append_nodup() instead of string_list_append() to hand
over ownership of a detached strbuf and thus avoid leaking its memory.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

am: release strbuf after use in split_mail_mbox()

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

launch_editor(): indicate that Git waits for user input

When a graphical GIT_EDITOR is spawned by a Git command that opens
and waits for user input (e.g. "git rebase -i"), then the editor window
might be obscured by other windows. The user might be left staring at
the original Git terminal window without even realizing that s/he needs
to interact with another window before Git can proceed. To this user Git
appears hanging.

Print a message that Git is waiting for editor input in the original
terminal and get rid of it when the editor returns, if the terminal
supports erasing the last line.  Also, make sure that our message is
terminated with a whitespace so that any message the editor may show
upon starting up will be kept separate from our message.

Power users might not want to see this message or their editor might
already print such a message (e.g. emacsclient). Allow these users to
suppress the message by disabling the "advice.waitingForEditor" config.

The standard advise() function is not used here as it would always add
a newline which would make deleting the message harder.

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

setup.c: fix comment about order of .git directory discovery

Since gitfiles were introduced in b44ebb19e (Add platform-independent
.git "symlink", 2008-02-20) the order of checks during .git directory
discovery is: gitfile, gitdir, bare repo.  However, that commit did
only partially update the in-code comment describing this order,
missing the last line which still puts gitdir before gitfile.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff-tree: read the index so attribute checks work in bare repositories

A regression was introduced in 557a5998d (submodule: remove
gitmodules_config, 2017-08-03) to how attribute processing was handled
in bare repositories when running the diff-tree command.

By default the attribute system will first try to read ".gitattribute"
files from the working tree and then falls back to reading them from the
index if there isn't a copy checked out in the worktree.  Prior to
557a5998d the index was read as a side effect of the call to
'gitmodules_config()' which ensured that the index was already populated
before entering the attribute subsystem.

Since the call to 'gitmodules_config()' was removed the index is no
longer being read so when the attribute system tries to read from the
in-memory index it doesn't find any ".gitattribute" entries effectively
ignoring any configured attributes.

Fix this by explicitly reading the index during the setup of diff-tree.

Reported-by: Ben Boeckel <ben.boeckel@kitware.com>
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-prompt: fix reading files with windows line endings

If any of the files read by __git_eread have \r\n line endings, read
will only strip \n, leaving \r. This results in an ugly prompt, where
instead of

    user@pc MINGW64 /path/to/repo (BARE:master)

the last parenthesis is printed over the beginning of the prompt like

    )ser@pc MINGW64 /path/to/repo (BARE:master

This patch fixes the issue by changing the internal field separator
variable IFS to $'\r\n' before using the read builtin command.

Note that ANSI-C Quoting/POSIX Quoting ($'...') is supported by bash
as well as zsh, which are the current targets of git-prompt, cf.
contrib/completion/git-prompt.sh.

Signed-off-by: Robert Abel <rabel@robertabel.eu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-prompt: make __git_eread intended use explicit

__git_eread is used to read a single line of a given file (if it exists)
into a single variable stripping the EOL.
This patch removes the unused capability to split file contents into tokens
by passing multiple variable names. Add a comment and explicitly use $2
instead of misleading $@ as argument to the read builtin command.

Signed-off-by: Robert Abel <rabel@robertabel.eu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add worktree.guessRemote config option

Some users might want to have the --guess-remote option introduced in
the previous commit on by default, so they don't have to type it out
every time they create a new worktree.

Add a config option worktree.guessRemote that allows users to configure
the default behaviour for themselves.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

worktree: add --guess-remote flag to add subcommand

Currently 'git worktree add <path>' creates a new branch named after the
basename of the <path>, that matches the HEAD of whichever worktree we
were on when calling "git worktree add <path>".

It's sometimes useful to have 'git worktree add <path> behave more like
the dwim machinery in 'git checkout <new-branch>', i.e. check if the new
branch name, derived from the basename of the <path>, uniquely matches
the branch name of a remote-tracking branch, and if so check out that
branch and set the upstream to the remote-tracking branch.

Add a new --guess-remote option that enables exactly that behaviour.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

trace: improve performance while category is disabled

Move just enough code from trace.c into trace.h header so all code
necessary to determine that trace is disabled could be inlined to
calling functions.  Then perform the check if the trace key is
enabled sooner in call chain.

Signed-off-by: Gennady Kupava <gkupava@bloomberg.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

RelNotes: the eighth batch

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

Sync with maint

Merge branch 'jn/ssh-wrappers'

The ssh-variant 'simple' introduced earlier broke existing
installations by not passing --port/-4/-6 and not diagnosing an
attempt to pass these as an error.  Instead, default to
automatically detect how compatible the GIT_SSH/GIT_SSH_COMMAND is
to OpenSSH convention and then error out an invocation to make it
easier to diagnose connection errors.

* jn/ssh-wrappers:
  connect: correct style of C-style comment
  ssh: 'simple' variant does not support --port
  ssh: 'simple' variant does not support -4/-6
  ssh: 'auto' variant to select between 'ssh' and 'simple'
  connect: split ssh option computation to its own function
  connect: split ssh command line options into separate function
  connect: split git:// setup into a separate function
  connect: move no_fork fallback to git_tcp_connect
  ssh test: make copy_ssh_wrapper_as clean up after itself

Merge branch 'bw/protocol-v1'

A new mechanism to upgrade the wire protocol in place is proposed
and demonstrated that it works with the older versions of Git
without harming them.

* bw/protocol-v1:
  Documentation: document Extra Parameters
  ssh: introduce a 'simple' ssh variant
  i5700: add interop test for protocol transition
  http: tell server that the client understands v1
  connect: tell server that the client understands v1
  connect: teach client to recognize v1 server response
  upload-pack, receive-pack: introduce protocol version 1
  daemon: recognize hidden request arguments
  protocol: introduce protocol extension mechanisms
  pkt-line: add packet_write function
  connect: in ref advertisement, shallows are last

Merge branch 'sp/doc-info-attributes'

Doc update.

* sp/doc-info-attributes:
  doc: Mention info/attributes in gitrepository-layout

Merge branch 'ph/stash-save-m-option-fix'

In addition to "git stash -m message", the command learned to
accept "git stash -mmessage" form.

* ph/stash-save-m-option-fix:
  stash: learn to parse -m/--message like commit does

Merge branch 'jk/fewer-pack-rescan'

Internaly we use 0{40} as a placeholder object name to signal the
codepath that there is no such object (e.g. the fast-forward check
while "git fetch" stores a new remote-tracking ref says "we know
there is no 'old' thing pointed at by the ref, as we are creating
it anew" by passing 0{40} for the 'old' side), and expect that a
codepath to locate an in-core object to return NULL as a sign that
the object does not exist.  A look-up for an object that does not
exist however is quite costly with a repository with large number
of packfiles.  This access pattern has been optimized.

* jk/fewer-pack-rescan:
  sha1_file: fast-path null sha1 as a missing object
  everything_local: use "quick" object existence check
  p5551: add a script to test fetch pack-dir rescans
  t/perf/lib-pack: use fast-import checkpoint to create packs
  p5550: factor out nonsense-pack creation

Merge branch 'tg/deprecate-stash-save'

Doc update.

* tg/deprecate-stash-save:
  doc: prefer 'stash push' over 'stash save'

Merge branch 'rd/doc-notes-prune-fix'

Doc update.

* rd/doc-notes-prune-fix:
  notes: correct 'git notes prune' options to '[-n] [-v]'

Merge branch 'rd/man-reflog-add-n'

Doc update.

* rd/man-reflog-add-n:
  doc: add missing "-n" (dry-run) option to reflog man page

Merge branch 'rd/man-prune-progress'

Doc update.

* rd/man-prune-progress:
  prune: add "--progress" to man page and usage msg

Merge branch 'jt/submodule-tests-cleanup'

Further test clean-up.

* jt/submodule-tests-cleanup:
  Tests: clean up submodule recursive helpers

Merge branch 'jn/reproducible-build'

The build procedure has been taught to avoid some unnecessary
instability in the build products.

* jn/reproducible-build:
  generate-cmdlist: avoid non-deterministic output
  git-gui: sort entries in optimized tclIndex

Merge branch 'cc/git-packet-pm'

Code clean-up.

* cc/git-packet-pm:
  Git/Packet.pm: use 'if' instead of 'unless'
  Git/Packet: clarify that packet_required_key_val_read allows EOF

Merge branch 'ac/complete-pull-autostash'

The shell completion (in contrib/) learned that "git pull" can take
the "--autostash" option.

* ac/complete-pull-autostash:
  completion: add --autostash and --no-autostash to pull

Merge branch 'hm/config-parse-expiry-date'

"git config --expiry-date gc.reflogexpire" can read "2.weeks" from
the configuration and report it as a timestamp, just like "--int"
would read "1k" and report 1024, to help consumption by scripts.

* hm/config-parse-expiry-date:
  config: add --expiry-date

Merge branch 'tz/branch-doc-remove-set-upstream'

"git branch --set-upstream" has been deprecated and (sort of)
removed, as "--set-upstream-to" is the preferred one these days.
The documentation still had "--set-upstream" listed on its
synopsys section, which has been corrected.

* tz/branch-doc-remove-set-upstream:
  branch doc: remove --set-upstream from synopsis

Merge branch 'cc/perf-run-config'

* cc/perf-run-config:
  perf: store subsection results in "test-results/$GIT_PERF_SUBSECTION/"
  perf/run: show name of rev being built
  perf/run: add run_subsection()
  perf/run: update get_var_from_env_or_config() for subsections
  perf/run: add get_subsections()
  perf/run: add calls to get_var_from_env_or_config()
  perf/run: add GIT_PERF_DIRS_OR_REVS
  perf/run: add get_var_from_env_or_config()
  perf/run: add '--config' option to the 'run' script

Merge branch 'sb/submodule-recursive-checkout-detach-head'

"git checkout --recursive" may overwrite and rewind the history of
the branch that happens to be checked out in submodule
repositories, which might not be desirable.  Detach the HEAD but
still allow the recursive checkout to succeed in such a case.

* sb/submodule-recursive-checkout-detach-head:
  Documentation/checkout: clarify submodule HEADs to be detached
  recursive submodules: detach HEAD from new state

Prepare for 2.15.2

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

Merge branch 'jc/merge-base-fork-point-doc' into maint

Clarify and enhance documentation for "merge-base --fork-point", as
it was clear what it computed but not why/what for.

* jc/merge-base-fork-point-doc:
  merge-base --fork-point doc: clarify the example and failure modes

Merge branch 'tz/redirect-fix' into maint

A few scripts (both in production and tests) incorrectly redirected
their error output.  These have been corrected.

* tz/redirect-fix:
  rebase: fix stderr redirect in apply_autostash()
  t/lib-gpg: fix gpgconf stderr redirect to /dev/null

Merge branch 'tz/notes-error-to-stderr' into maint

"git notes" sent its error message to its standard output stream,
which was corrected.

* tz/notes-error-to-stderr:
  notes: send "Automatic notes merge failed" messages to stderr

Merge branch 'sb/test-cherry-pick-submodule-getting-in-a-way' into maint

The three-way merge performed by "git cherry-pick" was confused
when a new submodule was added in the meantime, which has been
fixed (or "papered over").

* sb/test-cherry-pick-submodule-getting-in-a-way:
  merge-recursive: handle addition of submodule on our side of history
  t/3512: demonstrate unrelated submodule/file conflict as cherry-pick failure

Merge branch 'pw/sequencer-recover-from-unlockable-index' into maint

The sequencer machinery (used by "git cherry-pick A..B", and "git
rebase -i", among other things) would have lost a commit if stopped
due to an unlockable index file, which has been fixed.

* pw/sequencer-recover-from-unlockable-index:
  sequencer: reschedule pick if index can't be locked

Merge branch 'rs/apply-inaccurate-eof-with-incomplete-line' into maint

"git apply --inaccurate-eof" when used with "--ignore-space-change"
triggered an internal sanity check, which has been fixed.

* rs/apply-inaccurate-eof-with-incomplete-line:
  apply: update line lengths for --inaccurate-eof

Merge branch 'tz/complete-branch-copy' into maint

Command line completion (in contrib/) has been taught about the
"--copy" option of "git branch".

* tz/complete-branch-copy:
  completion: add '--copy' option to 'git branch'

Merge branch 'ew/rebase-mboxrd' into maint

When "git rebase" prepared an mailbox of changes and fed it to "git
am" to replay them, it was confused when a stray "From " happened
to be in the log message of one of the replayed changes.  This has
been corrected.

* ew/rebase-mboxrd:
  rebase: use mboxrd format to avoid split errors

Merge branch 'sd/branch-copy' into maint

Code clean-up.

* sd/branch-copy:
  config: avoid "write_in_full(fd, buf, len) != len" pattern

Merge branch 'sw/pull-ipv46-passthru' into maint

Contrary to the documentation, "git pull -4/-6 other-args" did not
ask the underlying "git fetch" to go over IPv4/IPv6, which has been
corrected.

* sw/pull-ipv46-passthru:
  pull: pass -4/-6 option to 'git fetch'

Merge branch 'bc/submitting-patches-in-asciidoc' into maint

The SubmittingPatches document has been converted to produce an
HTML version via AsciiDoc/Asciidoctor.

* bc/submitting-patches-in-asciidoc:
  Documentation: convert SubmittingPatches to AsciiDoc
  Documentation: enable compat-mode for Asciidoctor

Merge branch 'mh/avoid-rewriting-packed-refs' into maint

Recent update to the refs infrastructure implementation started
rewriting packed-refs file more often than before; this has been
optimized again for most trivial cases.

* mh/avoid-rewriting-packed-refs:
  files-backend: don't rewrite the `packed-refs` file unnecessarily
  t1409: check that `packed-refs` is not rewritten unnecessarily

t2020: test variations that matter

Because our test suite is not about validating the working of the
shell, it is pointless to test variations of how a literal string
'yes' is quoted when assigned to an environment variable.

Instead, test various ways to spell 'yes' (we use strcasecmp() so
uppercased and capitalized variant should work just like 'yes'
spelled in all lowercase) and make sure we take them as 'yes'.  That
is more relevant in testing Git.

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

t4013: test new output from diff --abbrev --raw

Use newly-introduced finely-grained control to teach the diff-family to
honor the new environment GIT_PRINT_SHA1_ELLIPSIS and remove the
ellipses when it is not set.

Mentored-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ann T Ropea <bedhanger@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: diff_aligned_abbrev: remove ellipsis after abbreviated SHA-1 value

Neither Git nor the user are in need of this (visual) aid anymore, but
we must offer a transition period.

A follow-up patch (series) will rectify the situation by covering the
new output format as well as the backward compatible one.

Also, fix a typo: "abbbreviated" ---> "abbreviated".

Signed-off-by: Ann T Ropea <bedhanger@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t4013: prepare for upcoming "diff --raw --abbrev" output format change

Most of the t4013 tests go through a list of sample command lines,
and each of them is executed and its output compared with an
expected one stored in t4013/ directory.  Allow these lines to begin
with a colon followed by magic word(s) so that test conditions can
easily be tweaked.

The expected use that will happen in later steps of this is to run
tests expecting the traditional output and run the same test without
the GIT_PRINT_SHA1_ELLIPSIS=yes environment exported for (perhaps
some of) them, which will have to expect different output.  Since
all of the existing tests are meant to run with the environment,
use the magic word "noellipses" to cause the variable not to be set
and exported.

As this step does not add any new test with the magic word, all
tests still run with the environment variable, expecting the
traditional output, but it will change soon.

Based-on-patch-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ann T Ropea <bedhanger@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

checkout: describe_detached_head: remove ellipsis after committish

We do not want an ellipsis displayed following an (abbreviated) SHA-1
value.

The days when this was necessary to indicate the truncation to
lower-level Git commands and/or the user are bygone.

However, to ease the transition, the ellipsis will still be printed if
the user sets the environment variable GIT_PRINT_SHA1_ELLIPSIS to "yes".

Correct documentation with respect to what describe_detached_head prints
when GIT_PRINT_SHA1_ELLIPSIS is not set as indicated above.

Add tests for the old and new behaviour.

Signed-off-by: Ann T Ropea <bedhanger@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

hashmap: adjust documentation to reflect reality

The hashmap API is just complicated enough that even at least one
long-time Git contributor has to look up how to use it every time he
finds a new use case. When that happens, it is really useful if the
provided example code is correct...

While at it, "fix a memory leak", avoid statements before variable
declarations, fix a const -> no-const cast, several %l specifiers (which
want to be %ld), avoid using an undefined constant, call scanf()
correctly, use FLEX_ALLOC_STR() where appropriate, and adjust the style
here and there.

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

Documentation/git-clone: improve description for submodule recursing

There have been a few complaints on the mailing list that git-clone doesn't
respect the `submodule.recurse` setting, which every other command (that
potentially knows how to deal with submodules) respects.  In case of clone
this is not beneficial to respect as the user may not want to obtain all
submodules (assuming a pathspec of '.').

Improve the documentation such that the pathspec is mentioned in the
synopsis to alleviate the confusion around the submodule recursion flag
in git-clone.

While at it clarify that the option can be given multiple times for complex
pathspecs.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>