Merge branch 'jk/interop-test' into maint

Picking two versions of Git and running tests to make sure the
older one and the newer one interoperate happily has now become
possible.

* jk/interop-test:
t/interop: add test of old clients against modern git-daemon
t: add an interoperability test harness

Merge branch 'jt/perf-updates' into maint

The t/perf performance test suite was not prepared to test not so
old versions of Git, but now it covers versions of Git that are not
so ancient.

* jt/perf-updates:
t/perf: add fallback for pre-bin-wrappers versions of git
t/perf: use $MODERN_GIT for all repo-copying steps
t/perf: export variable used in other blocks

Merge branch 'rs/strbuf-add-real-path' into maint

An helper function to make it easier to append the result from
real_path() to a strbuf has been added.

* rs/strbuf-add-real-path:
strbuf: add strbuf_add_real_path()
cocci: use ALLOC_ARRAY

Merge branch 'jk/parse-config-key-cleanup' into maint

The "parse_config_key()" API function has been cleaned up.

* jk/parse-config-key-cleanup:
parse_hide_refs_config: tell parse_config_key we don't want a subsection
parse_config_key: allow matching single-level config
parse_config_key: use skip_prefix instead of starts_with
refs: parse_hide_refs_config to use parse_config_key

travis-ci: build and test Git on Windows

Most Git developers work on Linux and they have no way to know if their
changes would break the Git for Windows build. Let's fix that by adding
a job to TravisCI that builds and tests Git on Windows. Unfortunately,
TravisCI does not support Windows.

Therefore, we did the following:
* Johannes Schindelin set up a Visual Studio Team Services build
sponsored by Microsoft and made it accessible via an Azure Function
that speaks a super-simple API. We made TravisCI use this API to
trigger a build, wait until its completion, and print the build and
test results.
* A Windows build and test run takes up to 3h and TravisCI has a timeout
after 50min for Open Source projects. Since the TravisCI job does not
use heavy CPU/memory/etc. resources, the friendly TravisCI folks
extended the job timeout for git/git to 3h.

Things, that would need to be done:
* Someone with write access to https://travis-ci.org/git/git would need
to add the secret token as "GFW_CI_TOKEN" variable in the TravisCI
repository setting [1]. Afterwards the build should just work.

Things, that might need to be done:
* The Windows box can only process a single build at a time. A second
Windows build would need to wait until the first finishes. This
waiting time and the build time after the wait could exceed the 3h
threshold. If this is a problem, then it is likely to happen every day
as usually multiple branches are pushed at the same time (pu/next/
master/maint). I cannot test this as my TravisCI account has the 50min
timeout. One solution could be to limit the number of concurrent
TravisCI jobs [2].

[1] https://docs.travis-ci.com/user/environment-variables#Defining-Variables-in-Repository-Settings
[2] https://docs.travis-ci.com/user/customizing-the-build#Limiting-Concurrent-Builds

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

builtin/receive-pack: fix incorrect pointer arithmetic

If we had already processed the last newline in a push certificate, we
would end up subtracting NULL from the end-of-certificate pointer when
computing the length of the line. This would have resulted in an
absurdly large length, and possibly a buffer overflow. Instead,
subtract the beginning-of-certificate pointer from the
end-of-certificate pointer, which is what's expected.

Note that this situation should never occur, since not only do we
require the certificate to be newline terminated, but the signature will
only be read from the beginning of a line. Nevertheless, it seems
prudent to correct it.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

notes: do not break note_tree structure in note_tree_consolidate()

After a note is removed, note_tree_consolidate is called to eliminate
some useless nodes. The typical case is that if you had an int_node
with 2 PTR_TYPE_NOTEs in it, and remove one of them, then the
PTR_TYPE_INTERNAL pointer in the parent tree can be replaced with the
remaining PTR_TYPE_NOTE.

This works fine when PTR_TYPE_NOTEs are involved, but falls flat when
other types are involved.

To put things in more practical terms, let's say we start from an empty
notes tree, and add 3 notes:

- one for a sha1 that starts with 424
- one for a sha1 that starts with 428
- one for a sha1 that starts with 4c

To keep track of this, note_tree.root will have a PTR_TYPE_INTERNAL at
a[4], pointing to an int_node*.
In turn, that int_node* will have a PTR_TYPE_NOTE at a[0xc], pointing to
the leaf_node* with the key and value, and a PTR_TYPE_INTERNAL at a[2],
pointing to another int_node*.
That other int_node* will have 2 PTR_TYPE_NOTE, one at a[4] and the
other at a[8].

When looking for the note for the sha1 starting with 428, get_note() will
recurse through (simplified) root.a[4].a[2].a[8].

Now, if we remove the note for the sha1 that starts with 4c, we're left
with a int_node* with only one PTR_TYPE_INTERNAL entry in it. After
note_tree_consolidate runs, root.a[4] now points to what used to be
pointed at by root.a[4].a[2].

Which means looking up for the note for the sha1 starting with 428 now
fails because there is nothing at root.a[4].a[2] anymore: there is only
root.a[4].a[4] and root.a[4].a[8], which don't match the expected
structure for the lookup.

So if all there is left in an int_node* is a PTR_TYPE_INTERNAL pointer,
we can't safely remove it. I think the same applies for PTR_TYPE_SUBTREE
pointers. IOW, only PTR_TYPE_NOTEs are safe to be moved to the parent
int_node*.

This doesn't have a practical effect on git because all that happens
after a remove_note is a write_notes_tree, which just iterates the entire
note tree, but this affects anything using libgit.a that would try to do
lookups after removing notes.

Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sequencer: allow the commit-msg hooks to run during a `reword`

The `reword` command used to call `git commit` in a manner that asks for
the prepare-commit-msg and commit-msg hooks to do their thing.

Converting that part of the interactive rebase to C code introduced the
regression where those hooks were no longer run.

Let's fix this.

Note: the flag is called `VERIFY_MSG` instead of the more intuitive
`RUN_COMMIT_MSG_HOOKS` to indicate that the flag suppresses the
`--no-verify` flag (which may do other things in the future in addition
to suppressing the commit message hooks, too).

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

sequencer: make commit options more extensible

So far every time we need to tweak the behaviour of run_git_commit()
we have been adding a "int" parameter to it. As the function gains
parameters and different callsites having different needs, this is
becoming a maintenance burden. When a new knob needs to be added to
address a specific need for a single callsite, all the other callsites
need to add a "no, I do not want anything special with respect to the
new knob" argument.

Consolidate the existing four parameters into a flag word to make it
more maintainable, as we will be adding a new one to the mix soon.

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

l10n: de: translate describe debug terms

Signed-off-by: Michael J Gruber <git@grubix.eu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

describe: localize debug output fully

git describe --debug localizes all debug messages but not the terms
head, lightweight, annotated that it outputs for the candidates.
Localize them, too.

Signed-off-by: Michael J Gruber <git@grubix.eu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Eighth batch for 2.13

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

Merge branch 'km/config-grammofix'

Doc update.

* km/config-grammofix:
doc/config: grammar fixes for core.{editor,commentChar}

Merge branch 'sb/t3600-rephrase'

A test retitling.

* sb/t3600-rephrase:
t3600: rename test to describe its functionality

Merge branch 'sb/describe-broken'

"git describe --dirty" dies when it cannot be determined if the
state in the working tree matches that of HEAD (e.g. broken
repository or broken submodule). The command learned a new option
"git describe --broken" to give "$name-broken" (where $name is the
description of HEAD) in such a case.

* sb/describe-broken:
builtin/describe: introduce --broken flag

Merge branch 'sb/push-options-via-transport'

Recently we started passing the "--push-options" through the
external remote helper interface; now the "smart HTTP" remote
helper understands what to do with the passed information.

* sb/push-options-via-transport:
remote-curl: allow push options
send-pack: send push options correctly in stateless-rpc case

Merge branch 'km/t1400-modernization'

Code clean-up.

* km/t1400-modernization:
t1400: use test_when_finished for cleanup
t1400: remove a set of unused output files
t1400: use test_path_is_* helpers
t1400: set core.logAllRefUpdates in "logged by touch" tests
t1400: rename test descriptions to be unique

Merge branch 'jk/prefix-filename'

Code clean-up with minor bugfixes.

* jk/prefix-filename:
bundle: use prefix_filename with bundle path
prefix_filename: simplify windows #ifdef
prefix_filename: return newly allocated string
prefix_filename: drop length parameter
prefix_filename: move docstring to header file
hash-object: fix buffer reuse with --path in a subdirectory

Merge branch 'jc/lint-runaway-here-doc'

The test framework learned to detect unterminated here documents.

* jc/lint-runaway-here-doc:
tests: lint for run-away here-doc

Merge branch 'st/verify-tag'

A few unterminated here documents in tests were fixed, which in
turn revealed incorrect expectations the tests make. These tests
have been updated.

* st/verify-tag:
t7004, t7030: fix here-doc syntax errors

Merge branch 'sb/submodule-update-initial-runs-custom-script'

A test fix.

* sb/submodule-update-initial-runs-custom-script:
t7406: correct test case for submodule-update initial population

Merge branch 'jk/quote-env-path-list-component'

A test fix.

* jk/quote-env-path-list-component:
t5615: fix a here-doc syntax error

rev-parse: match @{upstream}, @{u} and @{push} case-insensitively

Change the revision parsing logic to match @{upstream}, @{u} & @{push}
case-insensitively.

Before this change supplying anything except the lower-case forms
emits an "unknown revision or path not in the working tree"
error. This change makes upper-case & mixed-case versions equivalent
to the lower-case versions.

The use-case for this is being able to hold the shift key down while
typing @{u} on certain keyboard layouts, which makes the sequence
easier to type, and reduces cases where git throws an error at the
user where it could do what he means instead.

These suffixes now join various other suffixes & special syntax
documented in gitrevisions(7) that matches case-insensitively. A table
showing the status of the various forms documented there before &
after this patch is shown below. The key for the table is:

- CI = Case Insensitive
- CIP = Case Insensitive Possible (without ambiguities)
- AG = Accepts Garbage (.e.g. @{./.4.minutes./.})

Before this change:

|----------------+-----+------+-----|
| What? | CI? | CIP? | AG? |
|----------------+-----+------+-----|
| @{<date>} | Y | Y | Y |
| @{upstream} | N | Y | N |
| @{push} | N | Y | N |
|----------------+-----+------+-----|

After it:

|----------------+-----+------+-----|
| What? | CI? | CIP? | AG? |
|----------------+-----+------+-----|
| @{<date>} | Y | Y | Y |
| @{upstream} | Y | Y | N |
| @{push} | Y | Y | N |
|----------------+-----+------+-----|

The ^{<type>} suffix is not made case-insensitive, because other
places that take <type> like "cat-file -t <type>" do want them case
sensitively (after all we never declared that type names are case
insensitive). Allowing case-insensitive typename only with this syntax
will make the resulting Git as a whole inconsistent.

This change was independently authored to scratch a longtime itch, but
when I was about to submit it I discovered that a similar patch had
been submitted unsuccessfully before by Conrad Irwin in August 2011 as
"rev-parse: Allow @{U} as a synonym for
@{u}" (<1313287071-7851-1-git-send-email-conrad.irwin@gmail.com>).

The tests for this patch are more exhaustive than in the 2011
submission. The starting point for them was to first change the code
to only support upper-case versions of the existing words, seeing what
broke, and amending the breaking tests to check upper case & mixed
case as appropriate, and where not redundant to other similar
tests. The implementation itself is equivalent.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD

FreeBSD implements getcwd(3) as a syscall, but falls back to a version
based on readdir(3) if it fails for some reason. The latter requires
permissions to read and execute path components, while the former does
not. That means that if our buffer is too small and we're missing
rights we could get EACCES, but we may succeed with a bigger buffer.

Keep retrying if getcwd(3) indicates lack of permissions until our
buffer can fit PATH_MAX bytes, as that's the maximum supported by the
syscall on FreeBSD anyway. This way we do what we can to be able to
benefit from the syscall, but we also won't loop forever if there is a
real permission issue.

This fixes a regression introduced with 7333ed17 (setup: convert
setup_git_directory_gently_1 et al. to strbuf, 2014-07-28) for paths
longer than 127 bytes with components that miss read or execute
permissions (e.g. 0711 on /home for privacy reasons); we used a fixed
PATH_MAX-sized buffer before.

Reported-by: Zenobiusz Kunegunda <zenobiusz.kunegunda@interia.pl>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc/SubmittingPatches: show how to get a CLI commit summary

Amend the section which describes how to get a commit summary to show
how do to that with "git show", currently the documentation only shows
how to do that with gitk.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/README: clarify the test_have_prereq documentation

Clarify the test_have_prereq documentation so that it's clear in the
reader's mind when the text says "most common use of this directly"
what the answer to "as opposed to what?" is.

Usually this function isn't used in lieu of using the prerequisite
support built into test_expect_*, mention that explicitly.

This changes documentation that I added in commit
9a897893a7 ("t/README: Document the prereq functions, and 3-arg
test_*", 2010-07-02).

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1dc: avoid CPP macro collisions

In an early part of sha1dc/sha1.c, the code checks the endianness of
the target platform by inspecting common CPP macros defined on
big-endian boxes, and sets BIGENDIAN macro to 1. If these common
CPP macros are not defined, the code declares that the target
platform is little endian and does nothing (most notably, it does
not #undef its BIGENDIAN macro).

The code that does so even has this comment

Note that all MSFT platforms are little endian,
so none of these will be defined under the MSC compiler.

and later, the defined-ness of the BIGENDIAN macro is used to switch
the implementation of sha1_load() macro.

One thing the code did not anticipate is that somebody might define
BIGENDIAN macro in some header it includes to 0 on a little-endian
target platform. Because the auto-detection based on common macros
do not touch BIGENDIAN macro when it detects a little-endian target,
such a definition is still valid and then defined-ness test will say
"Ah, BIGENDIAN is defined" and takes the wrong sha1_load().

As this auto-detection logic pretends as if it owns the BIGENDIAN
macro by ignoring the setting that may come from the outside and by
not explicitly unsetting when it decides that it is working for a
little-endian target, solve this problem without breaking that
assumption. Namely, we can rename BIGENDIAN this code uses to
something much less generic, i.e. SHA1DC_BIGENDIAN. For extra
protection, undef the macro on a little-endian target.

It is possible to work it around by instead #undef BIGENDIAN in
the auto-detection code, but a macro (or include) that happens later
in the code can be implemented in terms of BIGENDIAN on Windows and
it is possible that the implementation gets upset when it sees the
CPP macro undef'ed (instead of set to 0). Renaming the private macro
intended to be used only in this file to a less generic name relieves
us from having to worry about that kind of breakage.

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

Sync with 2.12.2

Seventh batch for 2.13

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

Merge branch 'jk/sha1dc'

The "detect attempt to create collisions" variant of SHA-1
implementation by Marc Stevens (CWI) and Dan Shumow (Microsoft)
has been integrated and made the default.

* jk/sha1dc:
Makefile: make DC_SHA1 the default
t0013: add a basic sha1 collision detection test
Makefile: add DC_SHA1 knob
sha1dc: disable safe_hash feature
sha1dc: adjust header includes for git
sha1dc: add collision-detecting sha1 implementation

Merge branch 'sg/test-with-stdin'

Teach the "debug" helper used in the test framework that allows a
command to run under "gdb" to make the session interactive.

* sg/test-with-stdin:
tests: make the 'test_pause' helper work in non-verbose mode
tests: create an interactive gdb session with the 'debug' helper

Merge branch 'rs/update-hook-optim'

Code clean-up.

* rs/update-hook-optim:
receive-pack: simplify run_update_post_hook()

Merge branch 'rs/shortlog-cleanup'

Code clean-up.

* rs/shortlog-cleanup:
shortlog: don't set after_subject to an empty string

Merge branch 'rs/path-name-safety-cleanup'

Code clean-up.

* rs/path-name-safety-cleanup:
revision: remove declaration of path_name()

Merge branch 'rs/http-push-cleanup'

Code clean-up.

* rs/http-push-cleanup:
http-push: don't check return value of lookup_unknown_object()

Merge branch 'js/regexec-buf'

Fix for potential segv introduced in v2.11.0 and later (also
v2.10.2).

* js/regexec-buf:
pickaxe: fix segfault with '-S<...> --pickaxe-regex'

Merge branch 'jk/execv-dashed-external'

Fix for NO_PTHREADS build.

* jk/execv-dashed-external:
run-command: fix segfault when cleaning forked async process

Merge branch 'dl/credential-cache-socket-in-xdg-cache'

The default location "~/.git-credential-cache/socket" for the
socket used to communicate with the credential-cache daemon has
been moved to "~/.cache/git/credential/socket".

* dl/credential-cache-socket-in-xdg-cache:
credential-cache: add tests for XDG functionality
credential-cache: use XDG_CACHE_HOME for socket
path.c: add xdg_cache_home

Git 2.12.2

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

Merge branch 'ab/doc-no-option-notation-fix' into maint

Doc fix.

* ab/doc-no-option-notation-fix:
doc: change erroneous --[no]-whatever into --[no-]whatever

Merge branch 'ab/push-default-doc-fix' into maint

Doc fix.

* ab/push-default-doc-fix:
push: mention "push.default=tracking" in the documentation

Merge branch 'nd/commit-hook-doc-fix' into maint

Doc fix.

* nd/commit-hook-doc-fix:
git-commit.txt: list post-rewrite in HOOKS section

Merge branch 'jc/config-case-cmdline-take-2' into maint

The code to parse "git -c VAR=VAL cmd" and set configuration
variable for the duration of cmd had two small bugs, which have
been fixed.
This supersedes jc/config-case-cmdline topic that has been discarded.

* jc/config-case-cmdline-take-2:
config: use git_config_parse_key() in git_config_parse_parameter()
config: move a few helper functions up

Merge branch 'jk/grep-no-index-fix' into maint

The code to parse the command line "git grep <patterns>... <rev>
[[--] <pathspec>...]" has been cleaned up, and a handful of bugs
have been fixed (e.g. we used to check "--" if it is a rev).

* jk/grep-no-index-fix:
grep: treat revs the same for --untracked as for --no-index
grep: do not diagnose misspelt revs with --no-index
grep: avoid resolving revision names in --no-index case
grep: fix "--" rev/pathspec disambiguation
grep: re-order rev-parsing loop
grep: do not unnecessarily query repo for "--"
grep: move thread initialization a little lower

Merge branch 'jn/remote-helpers-with-git-dir' into maint

"git ls-remote" and "git archive --remote" are designed to work
without being in a directory under Git's control. However, recent
updates revealed that we randomly look into a directory called
.git/ without actually doing necessary set-up when working in a
repository. Stop doing so.

* jn/remote-helpers-with-git-dir:
remote helpers: avoid blind fall-back to ".git" when setting GIT_DIR
remote: avoid reading $GIT_DIR config in non-repo

Merge branch 'sb/submodule-config-parse-ignore-fix' into maint

Code to read submodule.<name>.ignore config did not state the
variable name correctly when giving an error message diagnosing
misconfiguration.

* sb/submodule-config-parse-ignore-fix:
submodule-config: correct error reporting for invalid ignore value

Merge branch 'jk/push-deadlock-regression-fix' into maint

"git push" had a handful of codepaths that could lead to a deadlock
when unexpected error happened, which has been fixed.

* jk/push-deadlock-regression-fix:
send-pack: report signal death of pack-objects
send-pack: read "unpack" status even on pack-objects failure
send-pack: improve unpack-status error messages
send-pack: use skip_prefix for parsing unpack status
send-pack: extract parsing of "unpack" response
receive-pack: fix deadlock when we cannot create tmpdir

pack.h: define largest possible encoded object size

Several callers use fixed buffers for storing the pack
object header, and they've picked 10 as a magic number. This
is reasonable, since it handles objects up to 2^67. But
let's give them a constant so it's clear that the number
isn't pulled out of thin air.

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

encode_in_pack_object_header: respect output buffer length

The encode_in_pack_object_header() writes a variable-length
header to an output buffer, but it doesn't actually know
long the buffer is. At first glance, this looks like it
might be possible to overflow.

In practice, this is probably impossible. The smallest
buffer we use is 10 bytes, which would hold the header for
an object up to 2^67 bytes. Obviously we're not likely to
see such an object, but we might worry that an object could
lie about its size (causing us to overflow before we realize
it does not actually have that many bytes). But the argument
is passed as a uintmax_t. Even on systems that have __int128
available, uintmax_t is typically restricted to 64-bit by
the ABI.

So it's unlikely that a system exists where this could be
exploited. Still, it's easy enough to use a normal out/len
pair and make sure we don't write too far. That protects the
hypothetical 128-bit system, makes it harder for callers to
accidentally specify a too-small buffer, and makes the
resulting code easier to audit.

Note that the one caller in fast-import tried to catch such
a case, but did so _after_ the call (at which point we'd
have already overflowed!). This check can now go away.

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

fast-import: use xsnprintf for formatting headers

The stream_blob() function checks the return value of
snprintf and dies. This is more simply done with
xsnprintf (and matches the similar call in store_object).

The message the user would get is less specific, but since
the point is that this _shouldn't_ ever happen, that's OK.

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

fast-import: use xsnprintf for writing sha1s

When we have to write a sha1 with a newline, we do so by
copying both into a single buffer, so that we can issue a
single write() call.

We use snprintf but don't bother to check the output, since
we know it will fit. However, we should use xsnprintf() in
such a case so that we're notified if our assumption turns
out to be wrong (and to make it easier to audit for
unchecked snprintf calls).

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

mailmap: use Michael J Gruber's new address

Map both old addresses to the new, hopefully more permanent one.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Michael J Gruber <git@grubix.eu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tag: add tests for --with and --without

Change the test suite to test for these synonyms for --contains and
--no-contains, respectively.

Before this change there were no tests for them at all. This doesn't
exhaustively test for them as well as their --contains and
--no-contains synonyms, but at least it's something.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ref-filter: reflow recently changed branch/tag/for-each-ref docs

Reflow the recently changed branch/tag-for-each-ref
documentation. This change shows no changes under --word-diff, except
the innocuous change of moving git-tag.txt's "[--sort=<key>]" around
slightly.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ref-filter: add --no-contains option to tag/branch/for-each-ref

Change the tag, branch & for-each-ref commands to have a --no-contains
option in addition to their longstanding --contains options.

This allows for finding the last-good rollout tag given a known-bad
<commit>. Given a hypothetically bad commit cf5c7253e0, the git
version to revert to can be found with this hacky two-liner:

(git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') |
sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10

With this new --no-contains option the same can be achieved with:

git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10

As the filtering machinery is shared between the tag, branch &
for-each-ref commands, implement this for those commands too. A
practical use for this with "branch" is e.g. finding branches which
were branched off between v2.8.0 and v2.10.0:

git branch --contains v2.8.0 --no-contains v2.10.0

The "describe" command also has a --contains option, but its semantics
are unrelated to what tag/branch/for-each-ref use --contains for. A
--no-contains option for "describe" wouldn't make any sense, other
than being exactly equivalent to not supplying --contains at all,
which would be confusing at best.

Add a --without option to "tag" as an alias for --no-contains, for
consistency with --with and --contains. The --with option is
undocumented, and possibly the only user of it is
Junio (<xmqqefy71iej.fsf@gitster.mtv.corp.google.com>). But it's
trivial to support, so let's do that.

The additions to the the test suite are inverse copies of the
corresponding --contains tests. With this change --no-contains for
tag, branch & for-each-ref is just as well tested as the existing
--contains option.

In addition to those tests, add a test for "tag" which asserts that
--no-contains won't find tree/blob tags, which is slightly
unintuitive, but consistent with how --contains works & is documented.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tag: change --point-at to default to HEAD

Change the --points-at option to default to HEAD for consistency with
its siblings --contains, --merged etc. which default to
HEAD. Previously we'd get:

$ git tag --points-at 2>&1 | head -n 1
error: option `points-at' requires a value

This changes behavior added in commit ae7706b9ac (tag: add --points-at
list option, 2012-02-08).

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tag: implicitly supply --list given another list-like option

Change the "tag" command to implicitly turn on its --list mode when
provided with a list-like option such as --contains, --points-at etc.

This is for consistency with how "branch" works. When "branch" is
given a list-like option, such as --contains, it implicitly provides
--list. Before this change "tag" would error out on those sorts of
invocations. I.e. while both of these worked for "branch":

git branch --contains v2.8.0 <pattern>
git branch --list --contains v2.8.0 <pattern>

Only the latter form worked for "tag":

git tag --contains v2.8.0 '*rc*'
git tag --list --contains v2.8.0 '*rc*'

Now "tag", like "branch", will implicitly supply --list when a
list-like option is provided, and no other conflicting non-list
options (such as -d) are present on the command-line.

Spelunking through the history via:

git log --reverse -p -G'only allowed with' -- '*builtin*tag*c'

Reveals that there was no good reason for not allowing this in the
first place. The --contains option added in 32c35cfb1e ("git-tag: Add
--contains option", 2009-01-26) made this an error. All the other
subsequent list-like options that were added copied its pattern of
making this usage an error.

The only tests that break as a result of this change are tests that
were explicitly checking that this "branch-like" usage wasn't
permitted. Change those failing tests to check that this invocation
mode is permitted, add extra tests for the list-like options we
weren't testing, and tests to ensure that e.g. we don't toggle the
list mode in the presence of other conflicting non-list options.

With this change errors messages such as "--contains option is only
allowed with -l" don't make sense anymore, since options like
--contain turn on -l. Instead we error out when list-like options such
as --contain are used in conjunction with conflicting options such as
-d or -v.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tag: change misleading --list <pattern> documentation

Change the documentation for --list so that it's described as a
toggle, not as an option that takes a <pattern> as an argument.

Junio initially documented this in b867c7c23a ("git-tag: -l to list
tags (usability).", 2006-02-17), but later Jeff King changed "tag" to
accept multiple patterns in 588d0e834b ("tag: accept multiple patterns
for --list", 2011-06-20).

However, documenting this as "-l <pattern>" was never correct, as
these both worked before Jeff's change:

git tag -l 'v*'
git tag 'v*' -l

One would expect an option that was documented like that to only
accept:

git tag --list
git tag --list 'v*rc*'

And after Jeff's change, one that took multiple patterns:

git tag --list 'v*rc*' --list '*2.8*'

But since it's actually a toggle all of these work as well, and
produce identical output to the last example above:

git tag --list 'v*rc*' '*2.8*'
git tag --list 'v*rc*' '*2.8*' --list --list --list
git tag --list 'v*rc*' '*2.8*' --list -l --list -l --list

Now the documentation is more in tune with how the "branch" command
describes its --list option since commit cddd127b9a ("branch:
introduce --list option", 2011-08-28).

Change the test suite to assert that these invocations work for the
cases that weren't already being tested for.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

parse-options: add OPT_NONEG to the "contains" option

Add the OPT_NONEG flag to the "contains" option and its hidden synonym
"with". Since this was added in commit 694a577519 ("git-branch
--contains=commit", 2007-11-07) giving --no-{contains,with} hasn't
been an error, but has emitted the help output since
filter.with_commit wouldn't get set.

Now git will emit "error: unknown option `no-{contains,with}'" at the
top of the help output.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tag: add more incompatibles mode tests

Amend the test suite to test for more invalid uses like "-l -a"
etc.

This change tests the code path in builtin/tag.c between lines:

if (argc == 0 && !cmdmode)

And:

if ((create_tag_object || force) && (cmdmode != 0))

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pager_in_use: use git_env_bool()

The pager_in_use() function predates git_env_bool(), but
ends up doing the same thing. Let's make use of the latter,
which is shorter and less repetitive.

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

name-hash: add test-lazy-init-name-hash to .gitignore

Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

name-hash: add perf test for lazy_init_name_hash

Created t/perf/p0004-lazy-init-name-hash.sh test
to demonstrate correctness and performance gains
with the multithreaded version of lazy_init_name_hash().

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

name-hash: add test-lazy-init-name-hash

Add t/helper/test-lazy-init-name-hash.c test code
to demonstrate performance times for lazy_init_name_hash()
using the original single-threaded and the new multi-threaded
code paths.

Includes a --dump option to dump the created hashmaps to
stdout. You can use this to run both code paths and
confirm that they generate the same hashmaps.

Includes a --analyze option to analyze performance of both
code paths over a range of index sizes to help you find a
lower bound for the LAZY_THREAD_COST in name-hash.c.
For example, passing "-a 4000" will set "istate.cache_nr"
to 4000 and then try the multi-threaded code -- probably
giving 2 threads with 2000 entries each. It will then
run both the single-threaded (1x4000) and the multi-threaded
(2x2000) and compare the times. It will then repeat the
test with 8000, 12000, and etc. so that you can see the
cross over.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

name-hash: perf improvement for lazy_init_name_hash

Improve performance of lazy_init_name_hash() when
ignore_case is set. Teach name-hash to build the
istate.name_hash and istate.dir_hash simultaneously
using a forward-diving technique on the pathname
of the index_entry, rather than adding name_hash
entries and then searching backwards in the pathname
for parent directories.

This borrows algorithm ideas from clear_ce_flags_{1,dir}.

Multiple threads are used with the new algorithm to
speed hashmap construction.

This new code path is only used when threads are present
(a compiler settings) and when the index is large enough
to warrant the pthread complexity.

The code in clear_ce_flags_dir() uses a linear search to
find the adjacent index entries with the same prefix; a
binary search is used here handle_range_dir() to further
speed things up.

The size of LAZY_THREAD_COST was determined from rough
analysis using:
t/helper/test-lazy-init-name-hash --analyze

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

log: if --decorate is not given, default to --decorate=auto

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7004, t7030: fix here-doc syntax errors

Jan Palus noticed that some here-doc are spelled incorrectly,
resulting the entire remainder of the test snippet being slurped
into the "expect" file as if it were data, e.g. in this sequence

cat >expect <<EOF &&
... expectation ...
EOF
git $cmd_being_tested >actual &&
test_cmp expect actual

the last command of the test is "cat" that sends everything to
'expect' and succeeds.

Fixing these issues in t7004 and t7030 reveals that "git tag -v"
and "git verify-tag" with their --format option do not work as the
test was expecting originally. Instead of showing both valid tags
and tags with incorrect signatures on their output, tags that do not
pass verification are omitted from the output. Another breakage that
is uncovered is that these tests must be restricted to environment
where gpg is available.

Arguably, that is a safer behaviour, and because the format
specifiers like %(tag) do not have a way to show if the signature
verifies correctly, the command with the --format option cannot be
used to get a list of tags annotated with their signature validity
anyway.

For now, let's fix the here-doc syntax, update the expectation to
match the reality, and update the test prerequisite.

Maybe later when we extend the --format language available to "git
tag -v" and "git verify-tag" to include things like "%(gpg:status)",
we may want to change the behaviour so that piping a list of tag
names into

xargs git verify-tag --format='%(gpg:status) %(tag)'

becomes a good way to produce such a list, but that is a separate
topic.

Noticed-by: Jan Palus <jan.palus@gmail.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Santiago Torres <santiago@nyu.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

branch doc: update description for `--list`

The paragraph begins with a sample command line `git branch <name>`
that has nothing to do with the option being described. Remove it,
but use the space to instead show that multiple patterns can be
given.

Also mention the unfortunate `-l` that can be easily confused with
it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

branch doc: change `git branch <pattern>` to use `<branchname>`

Change an example for `git branch <pattern>` to say `git branch
<branchname>` to be consistent with the synopsis. This changes
documentation added in d8d33736b5 ("branch: allow pattern arguments",
2011-08-28).

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: lint for run-away here-doc

We found a few run-away here documents that are started with an
end-of-here-doc marker that is incorrectly spelled, e.g.

git some command >actual &&
cat <<EOF >expect
...
EOF &&
test_cmp expect actual

which ends up slurping the entire remainder of the script as if it
were the data. Often the command that gets misused like this exits
without failure (e.g. "cat" in the above example), which makes the
command appear to work, without ever executing the remainder of the
test.

Piggy-back on the test that catches &&-chain breakage to detect this
case as well.

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

completion: offer ctags symbol names for 'git log -S', '-G' and '-L:'

Just like in the case of search patterns for 'git grep', see 29eec71f2
(completion: match ctags symbol names in grep patterns, 2011-10-21)),
a common thing to look for using 'git log -S', '-G' and '-L:' is the
name of a symbol.

Teach the completion for 'git log' to offer ctags symbol names after
these options, both in stuck and in unstuck forms.

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

completion: extract completing ctags symbol names into helper function

The previous commit doubled the number of __git_match_ctag()'s
positional parameters, and, to keep the position of existing
parameters for the sake of backwards compatibility, the prefix,
current word and suffix parameters ended up in different order than in
other functions accepting the same parameters. Then there is a
condition checking the existence of the tag file before invoking this
function.

We could still live with this if there were only a single callsite,
but the next commit will add a few more, so it's worth providing a
cleaner interface.

Add the wrapper function __git_complete_symbol(), which encompasses
the condition for checking the presence of the tag file and filling
COMPREPLY, and accepts '--opt=val'-style options with default values
that keep callsites simpler.

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

completion: put matching ctags symbol names directly into COMPREPLY

The one-liner awk script in __git_match_ctag() listing ctags symbol
names for 'git grep <TAB>' is already smart enough to list only symbol
names matching the current word to be completed.

Extend this helper function to accept prefix and suffix parameters to
be prepended and appended, respectively, to each listed symbol name in
the awk script, so its output won't require any additional processing
or filtering in the completion script before being handed over to
Bash. Use the faster __gitcomp_direct() helper instead of
__gitcomp_nl() to fill the fully processed matching symbol names into
Bash's COMPREPLY array.

Right after 'git grep <TAB>' in current git.git with 14k+ symbol names
in the tag file, best of five:

Before:

$ time __gitcomp_nl "$(__git_match_ctag "" tags)"

real 0m0.178s
user 0m0.176s
sys 0m0.000s

After:

$ time __gitcomp_direct "$(__git_match_ctag "" tags "" " ")"

real 0m0.058s
user 0m0.048s
sys 0m0.008s

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

doc/config: grammar fixes for core.{editor,commentChar}

Signed-off-by: Kyle Meyer <kyle@kyleam.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

refs.c: use skip_prefix() in prettify_refname()

This eliminates three magic numbers.

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

Merge branch 'js/rebase-helper'

A hotfix for a regression fix

* js/rebase-helper:
sequencer: fix missing newline

sequencer: fix missing newline

When using rebase --interactive where one of the lines is marked as
'edit' this is the resulting output:

Stopped at ec3b9c4... stuffYou can amend the commit now, with

git commit --amend

Once you are satisfied with your changes, run

git rebase --continue

A newline character is missing at the end of the "Stopped at ..." line and
before the "You can amend ..." line. This patch fixes the malformed output by
adding the missing newline character to the end of the "Stopped at ..." line.

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

completion: speed up branch and tag completion

Modify __git_heads() and __git_tags() and the few callsites they have,
so we can let 'git for-each-ref' do all the hard work and these
functions' output won't need any further processing or filtering
before being handed over to Bash, resulting in faster branch and tag
completion. These are some of the same tricks used in the previous
commits to speed up refs completion, namely:

- Extend both functions to accept prefix, current word and suffix
positional parameters, all optional and all empty by default to
keep the parameterless behavior unaltered.

- Specify appropriate globbing patterns to 'git for-each-ref' to
list only branches or tags matching the given current word
parameter.

- Modify the 'git for-each-ref --format=<...>' to include the given
prefix and suffix.

- Adjust all callsites to specify the proper prefix, current word
and suffix parameters, and to fill COMPREPLY using
__gitcomp_direct().

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

completion: fill COMPREPLY directly when completing fetch refspecs

The __git_complete_fetch_refspecs() has to iterate over __git_refs()'s
output anyway to turn the listed matching refs into refspecs, and it
knows about the prefix and suffix that has to be added to each
refspec.

Modify this function to add the prefix and suffix to each refspec
while iterating and feed the result, since it doesn't need further
processing, to the new __gitcomp_direct() helper added in the previous
commit, because it should be faster when there are a lot of refspecs
to list.

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

completion: fill COMPREPLY directly when completing refs

__gitcomp_nl() iterates over all the possible completion words it gets
as argument

- filtering matching words,
- appending a trailing space to each matching word (in all but two
cases),
- prepending a prefix to each matching word (when completing words
after e.g. '--option=<TAB>' or 'master..<TAB>'), and
- adding each matching word to the COMPREPLY array.

This takes a while when a lot of refs are passed to __gitcomp_nl().

The previous changes in this series ensure that __git_refs() lists
only refs matching the current word to be completed, making a second
filtering in __gitcomp_nl() redundant.

Adding the necessary prefix and suffix could be done in __git_refs()
as well:

- When refs come from 'git for-each-ref', then that prefix and
suffix could be added much more efficiently using a 'git
for-each-ref' format containing said prefix and suffix. Care
should be taken, though, because that prefix might contain
'for-each-ref' format specifiers as part of the left hand side of
a '..' range or '...' symmetric difference notation or
fetch/push/etc. refspec, e.g. 'git log "evil-%(refname)..br<TAB>'.
Doubling every '%' in the prefix will prevent 'git for-each-ref'
from interpolating any of those contained specifiers.
- When refs come from 'git ls-remote', then that prefix and suffix
can be added in the shell loop that has to process 'git
ls-remote's output anyway.
- Finally, the prefix and suffix can be added to that handful of
potentially matching symbolic and pseudo refs right away in the
shell loop listing them.

And then all what is still left to do is to assign a bunch of
newline-separated words to a shell array, which can be done without a
shell loop iterating over each word, basically making all of
__gitcomp_nl() unnecessary for refs completion.

Add the helper function __gitcomp_direct() to fill the COMPREPLY array
with prefiltered and preprocessed words without any additional
processing, without a shell loop, with just one single compound
assignment. Modify __git_refs() to accept prefix and suffix
parameters and add them to each and every listed ref as described
above. Modify __git_complete_refs() to pass the prefix and suffix
parameters to __git_refs() and to feed __git_refs()'s output to
__gitcomp_direct() instead of __gitcomp_nl().

This speeds up refs completion when there are a lot of refs matching
the current word to be completed. Listing all branches for completion
in a repo with 100k local branches, all packed, best of five:

On Linux, near the beginning of this series, for reference:

$ time __git_complete_refs

real 0m2.028s
user 0m1.692s
sys 0m0.344s

Before this patch:

real 0m1.135s
user 0m1.112s
sys 0m0.024s

After:

real 0m0.367s
user 0m0.352s
sys 0m0.020s

On Windows, near the beginning:

real 0m13.078s
user 0m1.609s
sys 0m0.060s

Before this patch:

real 0m2.093s
user 0m1.641s
sys 0m0.060s

After:

real 0m0.683s
user 0m0.203s
sys 0m0.076s

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

completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery

When listing unique remote branches for 'git checkout's tracking
DWIMery, __git_refs() runs the classic '... |sort |uniq -u' pattern to
filter out duplicate remote branches.

Let 'git for-each-ref' do the sorting, sparing the overhead of
fork()+exec()ing 'sort' and a stage in the pipeline where potentially
relatively large amount of data can be passed between two subsequent
pipeline stages.

This speeds up refs completion for 'git checkout' a bit when a lot of
remote branches match the current word to be completed. Listing a
single local and 100k remote branches, all packed, best of five:

On Linux, before:

$ time __git_complete_refs --track

real 0m1.856s
user 0m1.816s
sys 0m0.060s

After:

real 0m1.550s
user 0m1.512s
sys 0m0.060s

On Windows, before:

real 0m3.128s
user 0m2.155s
sys 0m0.183s

After:

real 0m2.781s
user 0m1.826s
sys 0m0.136s

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

completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery

The code listing unique remote branches for 'git checkout's tracking
DWIMery outputs only remote branches that match the current word to be
completed, but the filtering is done in a shell loop iterating over
all remote refs.

Let 'git for-each-ref' do the filtering, as it can do so much more
efficiently and we can remove that shell loop entirely.

This speeds up refs completion for 'git checkout' considerably when
there are a lot of non-matching remote refs to be filtered out.
Uniquely completing a branch in a repository with 100k remote
branches, all packed, best of five:

On Linux, before:

$ time __git_complete_refs --cur=maste --track

real 0m1.993s
user 0m1.740s
sys 0m0.304s

After:

real 0m0.266s
user 0m0.248s
sys 0m0.012s

On Windows, before:

real 0m6.187s
user 0m3.358s
sys 0m2.121s

After:

real 0m0.750s
user 0m0.015s
sys 0m0.090s

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

completion: let 'for-each-ref' strip the remote name from remote branches

The code listing unique remote branches for 'git checkout's tracking
DWIMery uses a shell parameter expansion in a loop iterating over each
listed ref to remove the remote's name from the remote branches, i.e.
the leading path component from the short ref. When listing refs from
a configured remote repository, '| sed s///' is used for the same
purpose.

Let 'git for-each-ref' strip one more leading path component from the
refs, i.e. use the format 'refname:strip=3' instead of '=2', making
that parameter expansion and 'sed' execution unnecessary.

This speeds up refs completion for 'git checkout'. Uniquely
completing a branch for 'git checkout maste<TAB>' in a repo with 100k
remote branches, all packed, best of five:

On Linux, near the beginning of this series, for reference:

$ time __git_complete_refs --cur=maste --track

real 0m8.185s
user 0m6.896s
sys 0m1.616s

Before this patch:

real 0m2.714s
user 0m2.344s
sys 0m0.436s

After:

real 0m1.993s
user 0m1.740s
sys 0m0.304s

On Windows, near the beginning:

real 1m8.421s
user 0m7.591s
sys 0m3.557s

Before this patch:

real 0m8.191s
user 0m4.638s
sys 0m2.918s

After:

real 0m6.187s
user 0m3.358s
sys 0m2.121s

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

completion: let 'for-each-ref' and 'ls-remote' filter matching refs

When completing refs, several __git_refs() code paths list all the
refs from the refs/{heads,tags,remotes}/ hierarchy and then
__gitcomp_nl() iterates over those refs in a shell loop to filter out
refs not matching the current ref to be completed. This comes with a
considerable performance penalty when a repository contains a lot of
refs but the current ref can be uniquely completed or when only a
handful of refs match the current ref.

Reduce the number of iterations in __gitcomp_nl() from the number of
refs to the number of matching refs by specifying appropriate globbing
patterns to 'git for-each-ref' and 'git ls-remote' to list only those
refs that match the current ref to be completed. However, do so only
when the ref to match is explicitly given as parameter, because the
current word on the command line might contain a prefix like
'--option=' or 'branch..'. The __git_complete_refs() and
__git_complete_fetch_refspecs() helpers introduced previously in this
patch series already call __git_refs() specifying this current ref
parameter, so all their callsites, i.e. all places in the completion
script doing refs completion, can benefit from this optimization.

Furthermore, list only those symbolic and pseudo refs that match the
current ref to be completed. Though it doesn't matter at all in
itself performance-wise, it will allow us further significant
optimizations later in this series.

This speeds up refs completion considerably when there are a lot of
non-matching refs to be filtered out. Uniquely completing a branch in
a repository with 100k local branches, all packed, best of five:

On Linux, before:

$ time __git_complete_refs --cur=maste

real 0m0.831s
user 0m0.808s
sys 0m0.028s

After:

real 0m0.119s
user 0m0.104s
sys 0m0.008s

On Windows, before:

real 0m1.480s
user 0m1.031s
sys 0m0.060s

After:

real 0m0.377s
user 0m0.015s
sys 0m0.030s

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

completion: don't disambiguate short refs

When the completion script lists short refs it does so using the 'git
for-each-ref' format 'refname:short', which makes sure that all listed
refs are unambiguous. While disambiguating refs is technically
correct in this case, as opposed to the cases discussed in the
previous patch, this disambiguation involves several stat() syscalls
for each ref, thus, unfortunately, comes at a steep cost especially on
Windows and/or when there are a lot of refs to be listed. A user of
Git for Windows reported[1] 'git checkout <TAB>' taking ~11 seconds in
a repository with just about 4000 refs.

However, it's questionable whether ambiguous refs are really that bad
to justify that much extra cost:

- Ambiguous refs are not that common,
- even if a repository contains ambiguous refs, they only hurt when
the user actually happens to want to do something with one of the
ambiguous refs, and
- the issue can be easily circumvented by renaming those ambiguous
refs.

- On the other hand, apparently not that many refs are needed to
make refs completion unacceptably slow on Windows,
- and this slowness bites each and every time the user attempts refs
completion, even when the repository doesn't contain any ambiguous
refs.
- Furthermore, circumventing the issue might not be possible or
might be considerably more difficult and requires various
trade-offs (e.g. working in a repository with only a few selected
important refs while keeping a separate repository with all refs
for reference).

Arguably, in this case the benefits of technical correctness are
rather minor compared to the price we pay for it, and we are better
off opting for performance over correctness.

Use the 'git for-each-ref' format 'refname:strip=2' to list short refs
to spare the substantial cost of disambiguating.

This speeds up refs completion considerably. Uniquely completing a
branch in a repository with 100k local branches, all packed, best of
five:

On Linux, before:

$ time __git_complete_refs --cur=maste

real 0m1.662s
user 0m1.368s
sys 0m0.296s

After:

real 0m0.831s
user 0m0.808s
sys 0m0.028s

On Windows, before:

real 0m12.457s
user 0m1.016s
sys 0m0.092s

After:

real 0m1.480s
user 0m1.031s
sys 0m0.060s

[1] - https://github.com/git-for-windows/git/issues/524

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

completion: don't disambiguate tags and branches

When the completion script has to list only tags or only branches, it
uses the 'git for-each-ref' format 'refname:short', which makes sure
that all listed tags and branches are unambiguous. However,
disambiguating tags and branches in these cases is wrong, because:

- __git_tags(), the helper function listing possible tagname
arguments for 'git tag', lists an ambiguous tag
'refs/tags/ambiguous' as 'tags/ambiguous'. Its only consumer,
'git tag' expects its tagname argument to be under 'refs/tags/',
thus it interprets that abgiguous tag as
'refs/tags/tags/ambiguous'. Clearly wrong.

- __git_heads() lists possible branchname arguments for 'git branch'
and possible 'branch.<branchname>' configuration subsections.
Both of these expect branchnames to be under 'refs/heads/' and
misinterpret a disambiguated branchname like 'heads/ambiguous'.

Furthermore, disambiguation involves several stat() syscalls for each
tag or branch, thus comes at a steep cost especially on Windows and/or
when there are a lot of tags or branches to be listed.

Use the 'git for-each-ref' format 'refname:strip=2' instead of
'refname:short' to avoid harmful disambiguation of tags and branches
in __git_tags() and __git_heads().

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

completion: support excluding full refs

Commit 49416ad22 (completion: support excluding refs, 2016-08-24) made
possible to complete short refs with a '^' prefix.

Extend the support to full refs to make completing '^refs/...' work.

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

completion: support completing fully qualified non-fast-forward refspecs

After 'git fetch <remote> <TAB>' our completion script offers refspecs
that will fetch to a local branch with the same name as in the remote
repository, e.g. 'master:master'. This also completes
non-fast-forward refspecs, i.e. after a '+' prefix like
'+master:master', and fully qualified refspecs, e.g.
'refs/heads/master:refs/heads/master'. However, it does not complete
non-fast-forward fully qualified refspecs (or fully qualified refspecs
following any other prefix, e.g. '--option=', though currently no git
command supports such an option, but third party git commands might).

These refspecs are listed by the __git_refs2() function, which is just
a thin wrapper iterating over __git_refs()'s output, turning each
listed ref into a refspec. Now, it's certainly possible to modify
__git_refs2() and its callsite to pass an extra parameter containing
only the ref part of the current word to be completed (to follow suit
of the previous commit) to deal with prefixed fully qualified refspecs
as well. Unfortunately, keeping the current behavior unchanged in the
"no extra parameter" case brings in a bit of subtlety, which makes the
resulting code ugly and compelled me to write a 8-line long comment in
the proof of concept. Not good. However, since the callsite has to
be modified for proper functioning anyway, we might as well leave
__git_refs2() as is and introduce a new helper function without
backwards compatibility concerns.

Add the new function __git_complete_fetch_refspecs() that has all the
necessary parameters to do the right thing in all cases mentioned
above, including non-fast-forward fully qualified refspecs. This new
function can also easier benefit from optimizations coming later in
this patch series.

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

completion: support completing full refs after '--option=refs/<TAB>'

Completing full refs currently only works when the full ref stands on
in its own on the command line, but doesn't work when the current word
to be completed contains a prefix before the full ref, e.g.
'--option=refs/<TAB>' or 'master..refs/bis<TAB>'.

The reason is that __git_refs() looks at the current word to be
completed ($cur) as a whole to decide whether it has to list full (if
it starts with 'refs/') or short refs (otherwise). However, $cur also
holds said '--option=' or 'master..' prefixes, which of course throw
off this decision. Luckily, the default action is to list short refs,
that's why completing short refs happens to work even after a
'master..<TAB>' prefix and similar cases.

Pass only the ref part of the current word to be completed to
__git_refs() as a new positional parameter, so it can make the right
decision even if the whole current word contains some kind of a
prefix.

Make this new parameter the 4. positional parameter and leave the 3.
as an ignored placeholder for now (it will be used later in this patch
series).

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

completion: wrap __git_refs() for better option parsing

__git_refs() currently accepts two optional positional parameters: a
remote and a flag for 'git checkout's tracking DWIMery. To fix a
minor bug, and, more importantly, for faster refs completion, this
series will add three more parameters: a prefix, the current word to
be completed and a suffix, i.e. the options accepted by __gitcomp() &
friends, and will change __git_refs() to list only refs matching that
given current word and to add that given prefix and suffix to the
listed refs.

However, __git_refs() is the helper function that is most likely used
in users' custom completion scriptlets for their own git commands, and
we don't want to break those, so

- we can't change __git_refs()'s default output format, i.e. we
can't by default append a trailing space to every listed ref,
meaning that the suffix parameter containing the default trailing
space would have to be specified on every invocation, and

- we can't change the position of existing positional parameters
either, so there would have to be plenty of set-but-empty
placeholder positional parameters all over the completion script.

Furthermore, with five positional parameters it would be really hard
to remember which position means what.

To keep callsites simple, add the new wrapper function
__git_complete_refs() around __git_refs(), which:

- instead of positional parameters accepts real '--opt=val'-style
options and with minimalistic option parsing translates them to
__git_refs()'s and __gitcomp_nl()'s positional parameters, and

- includes the '__gitcomp_nl "$(__git_refs ...)" ...' command
substitution to make its behavior match its name and the behavior
of other __git_complete_* functions, and to limit future changes
in this series to __git_refs() and this new wrapper function.

Call this wrapper function instead of __git_refs() wherever possible
throughout the completion script, i.e. when __git_refs()'s output is
fed to __gitcomp_nl() right away without further processing, which
means all callsites except a single one in the __git_refs2() helper.

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

hashmap: document memihash_cont, hashmap_disallow_rehash api

Document memihash_cont() and hashmap_disallow_rehash()
in Documentation/technical/api-hashmap.txt.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

for-each-ref: partly change <object> to <commit> in help

Change mentions of <object> to <commit> in the help output of
for-each-ref as appropriate.

Both --[no-]merged and --contains only take commits, but --points-at
can take any object, such as a tag pointing to a tree or blob.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tag tests: fix a typo in a test description

Change "suceed" to "succeed" in a test description. The typo has been
here since the code was originally added in commit ef5a6fb597 ("Add
test-script for git-tag", 2007-06-28).

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tag: remove a TODO item from the test suite

Change the test for "git tag -l" to not have an associated TODO
comment saying that it should return non-zero if there's no tags.

This was added in commit ef5a6fb597 ("Add test-script for git-tag",
2007-06-28) when the tests for "tag" were initially added, but at this
point changing this would be inconsistent with how "git tag" is a
synonym for "git tag -l", and would needlessly break external code
that relies on this porcelain command.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ref-filter: add test for --contains on a non-commit

Change the tag test suite to test for --contains on a tree & blob. It
only accepts commits and will spew out "<object> is a tree, not a
commit".

It's sufficient to test this just for the "tag" and "branch" commands,
because it covers all the machinery shared between "branch" and
"for-each-ref".

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote-curl: allow push options

Teach remote-curl to understand push options and to be able to convey
them across HTTP.

Signed-off-by: Brandon Williams <bmwill@google.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-pack: send push options correctly in stateless-rpc case

"git send-pack --stateless-rpc" puts each request in a sequence of pkt-lines
followed by a flush-pkt. The push option code forgot about this and sends push
options and their terminating delimiter as ordinary pkt-lines that get their
length header stripped off by remote-curl before being sent to the server.

The result is multiple malformed requests, which the server rejects.

Fortunately send-pack --stateless-rpc already is aware of this "pkt-line within
pkt-line" framing for the update commands that precede push options. Handle
push options the same way.

Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Brandon Williams <bmwill@google.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7406: correct test case for submodule-update initial population

There are three issues with the test:

* The syntax of the here-doc was wrong, such that the entire test was
sucked into the here-doc, which is why the test succeeded.

* The variable $submodulesha1 was not expanded as it was inside a quoted
here text. We do not want to quote EOF marker for this.

* The redirection from the git command to the output file for comparison
was wrong as the -C operator from git doesn't apply to the redirect path.
Also we're interested in stderr of that command.

Noticed-by: Jan Palus <jan.palus@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/README: change "Inside <X> part" to "Inside the <X> part"

Change the mention of "Inside the <script> part, the standard
output..." to use the definite article, which makes more sense in this
context.

This changes documentation I originally added back in commit
20873f45e7 ("t/README: Document the do's and don'ts of tests",
2010-07-02).

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/README: link to metacpan.org, not search.cpan.org

Change a link to the web version of the TAP::Parser::Grammar
documentation to link to metacpan.org instead of search.cpan.org.

This is something I added back in commit 20873f45e7 ("t/README:
Document the do's and don'ts of tests", 2010-07-02), at the time
search.cpan.org was the more actively maintained CPAN web-interface,
nowadays that's metacpan.org.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>