summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2017-04-11Merge branch 'ab/ref-filter-no-contains'Libravatar Junio C Hamano4-14/+316
"git tag/branch/for-each-ref" family of commands long allowed to filter the refs by "--contains X" (show only the refs that are descendants of X), "--merged X" (show only the refs that are ancestors of X), "--no-merged X" (show only the refs that are not ancestors of X). One curious omission, "--no-contains X" (show only the refs that are not descendants of X) has been added to them. * ab/ref-filter-no-contains: tag: add tests for --with and --without ref-filter: reflow recently changed branch/tag/for-each-ref docs ref-filter: add --no-contains option to tag/branch/for-each-ref tag: change --point-at to default to HEAD tag: implicitly supply --list given another list-like option tag: change misleading --list <pattern> documentation parse-options: add OPT_NONEG to the "contains" option tag: add more incompatibles mode tests for-each-ref: partly change <object> to <commit> in help tag tests: fix a typo in a test description tag: remove a TODO item from the test suite ref-filter: add test for --contains on a non-commit ref-filter: make combining --merged & --no-merged an error tag doc: reword --[no-]merged to talk about commits, not tips tag doc: split up the --[no-]merged documentation tag doc: move the description of --[no-]merged earlier
2017-03-30Merge branch 'js/rebase-i-reword-to-run-hooks'Libravatar Junio C Hamano1-0/+17
A recent update to "rebase -i" stopped running hooks for the "git commit" command during "reword" action, which has been fixed. * js/rebase-i-reword-to-run-hooks: sequencer: allow the commit-msg hooks to run during a `reword` sequencer: make commit options more extensible t7504: document regression: reword no longer calls commit-msg
2017-03-30Merge branch 'ab/case-insensitive-upstream-and-push-marker'Libravatar Junio C Hamano2-6/+17
On many keyboards, typing "@{" involves holding down SHIFT key and one can easily end up with "@{Up..." when typing "@{upstream}". As the upstream/push keywords do not appear anywhere else in the syntax, we can safely accept them case insensitively without introducing ambiguity or confusion to solve this. * ab/case-insensitive-upstream-and-push-marker: rev-parse: match @{upstream}, @{u} and @{push} case-insensitively
2017-03-30Merge branch 'ab/test-readme-updates'Libravatar Junio C Hamano1-5/+7
Doc updates. * ab/test-readme-updates: t/README: clarify the test_have_prereq documentation t/README: change "Inside <X> part" to "Inside the <X> part" t/README: link to metacpan.org, not search.cpan.org
2017-03-30Merge branch 'rs/freebsd-getcwd-workaround'Libravatar Junio C Hamano1-0/+14
FreeBSD implementation of getcwd(3) behaved differently when an intermediate directory is unreadable/unsearchable depending on the length of the buffer provided, which our strbuf_getcwd() was not aware of. strbuf_getcwd() has been taught to cope with it better. * rs/freebsd-getcwd-workaround: strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD
2017-03-30Merge branch 'bw/recurse-submodules-relative-fix'Libravatar Junio C Hamano2-0/+114
A few commands that recently learned the "--recurse-submodule" option misbehaved when started from a subdirectory of the superproject. * bw/recurse-submodules-relative-fix: ls-files: fix bug when recursing with relative pathspec ls-files: fix typo in variable name grep: fix bug when recursing with relative pathspec setup: allow for prefix to be passed to git commands grep: fix help text typo
2017-03-30Merge branch 'sg/completion-refs-speedup'Libravatar Junio C Hamano1-0/+387
The refs completion for large number of refs has been sped up, partly by giving up disambiguating ambiguous refs and partly by eliminating most of the shell processing between 'git for-each-ref' and 'ls-remote' and Bash's completion facility. * sg/completion-refs-speedup: completion: speed up branch and tag completion completion: fill COMPREPLY directly when completing fetch refspecs completion: fill COMPREPLY directly when completing refs completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery completion: let 'for-each-ref' strip the remote name from remote branches completion: let 'for-each-ref' and 'ls-remote' filter matching refs completion: don't disambiguate short refs completion: don't disambiguate tags and branches completion: support excluding full refs completion: support completing fully qualified non-fast-forward refspecs completion: support completing full refs after '--option=refs/<TAB>' completion: wrap __git_refs() for better option parsing completion: remove redundant __gitcomp_nl() options from _git_commit()
2017-03-30Merge branch 'bw/submodule-is-active'Libravatar Junio C Hamano2-0/+243
"what URL do we want to update this submodule?" and "are we interested in this submodule?" are split into two distinct concepts, and then the way used to express the latter got extended, paving a way to make it easier to manage a project with many submodules and make it possible to later extend use of multiple worktrees for a project with submodules. * bw/submodule-is-active: submodule add: respect submodule.active and submodule.<name>.active submodule--helper init: set submodule.<name>.active clone: teach --recurse-submodules to optionally take a pathspec submodule init: initialize active submodules submodule: decouple url and submodule interest submodule--helper clone: check for configured submodules using helper submodule sync: use submodule--helper is-active submodule sync: skip work for inactive submodules submodule status: use submodule--helper is-active submodule--helper: add is-active subcommand
2017-03-28Merge branch 'jh/memihash-opt'Libravatar Junio C Hamano3-0/+284
The name-hash used for detecting paths that are different only in cases (which matter on case insensitive filesystems) has been optimized to take advantage of multi-threading when it makes sense. * jh/memihash-opt: name-hash: add test-lazy-init-name-hash to .gitignore name-hash: add perf test for lazy_init_name_hash name-hash: add test-lazy-init-name-hash name-hash: perf improvement for lazy_init_name_hash hashmap: document memihash_cont, hashmap_disallow_rehash api hashmap: add disallow_rehash setting hashmap: allow memihash computation to be continued name-hash: specify initial size for istate.dir_hash table
2017-03-28Merge branch 'tg/stash-push-fixup'Libravatar Junio C Hamano2-1/+23
Recent enhancement to "git stash push" command to support pathspec to allow only a subset of working tree changes to be stashed away was found to be too chatty and exposed the internal implementation detail (e.g. when it uses reset to match the index to HEAD before doing other things, output from reset seeped out). These, and other chattyness has been fixed. * tg/stash-push-fixup: stash: keep untracked files intact in stash -k stash: pass the pathspec argument to git reset stash: don't show internal implementation details
2017-03-28Merge branch 'sb/checkout-recurse-submodules'Libravatar Junio C Hamano3-24/+586
"git checkout" is taught the "--recurse-submodules" option. * sb/checkout-recurse-submodules: builtin/read-tree: add --recurse-submodules switch builtin/checkout: add --recurse-submodules switch entry.c: create submodules when interesting unpack-trees: check if we can perform the operation for submodules unpack-trees: pass old oid to verify_clean_submodule update submodules: add submodule_move_head submodule.c: get_super_prefix_or_empty update submodules: move up prepare_submodule_repo_env submodules: introduce check to see whether to touch a submodule update submodules: add a config option to determine if submodules are updated update submodules: add submodule config parsing make is_submodule_populated gently lib-submodule-update.sh: define tests for recursing into submodules lib-submodule-update.sh: replace sha1 by hash lib-submodule-update: teach test_submodule_content the -C <dir> flag lib-submodule-update.sh: do not use ./. as submodule remote lib-submodule-update.sh: reorder create_lib_submodule_repo submodule--helper.c: remove duplicate code connect_work_tree_and_git_dir: safely create leading directories
2017-03-27sequencer: allow the commit-msg hooks to run during a `reword`Libravatar Johannes Schindelin1-1/+1
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>
2017-03-27Merge branch 'sb/t3600-rephrase'Libravatar Junio C Hamano1-1/+1
A test retitling. * sb/t3600-rephrase: t3600: rename test to describe its functionality
2017-03-27Merge branch 'sb/describe-broken'Libravatar Junio C Hamano1-0/+20
"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
2017-03-27Merge branch 'sb/push-options-via-transport'Libravatar Junio C Hamano1-2/+31
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
2017-03-27Merge branch 'km/t1400-modernization'Libravatar Junio C Hamano1-76/+78
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
2017-03-27Merge branch 'jk/prefix-filename'Libravatar Junio C Hamano1-0/+10
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
2017-03-27Merge branch 'jc/lint-runaway-here-doc'Libravatar Junio C Hamano1-3/+3
The test framework learned to detect unterminated here documents. * jc/lint-runaway-here-doc: tests: lint for run-away here-doc
2017-03-27Merge branch 'st/verify-tag'Libravatar Junio C Hamano2-14/+10
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
2017-03-27Merge branch 'sb/submodule-update-initial-runs-custom-script'Libravatar Junio C Hamano1-3/+3
A test fix. * sb/submodule-update-initial-runs-custom-script: t7406: correct test case for submodule-update initial population
2017-03-27Merge branch 'jk/quote-env-path-list-component'Libravatar Junio C Hamano1-0/+1
A test fix. * jk/quote-env-path-list-component: t5615: fix a here-doc syntax error
2017-03-27rev-parse: match @{upstream}, @{u} and @{push} case-insensitivelyLibravatar Ævar Arnfjörð Bjarmason2-6/+17
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>
2017-03-26strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSDLibravatar René Scharfe1-0/+14
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>
2017-03-26t/README: clarify the test_have_prereq documentationLibravatar Ævar Arnfjörð Bjarmason1-3/+5
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>
2017-03-24Merge branch 'jk/sha1dc'Libravatar Junio C Hamano2-0/+19
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
2017-03-24Merge branch 'sg/test-with-stdin'Libravatar Junio C Hamano2-8/+4
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
2017-03-24Merge branch 'js/regexec-buf'Libravatar Junio C Hamano1-0/+5
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'
2017-03-24Merge branch 'dl/credential-cache-socket-in-xdg-cache'Libravatar Junio C Hamano1-0/+93
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
2017-03-24Merge branch 'jc/config-case-cmdline-take-2' into maintLibravatar Junio C Hamano1-0/+62
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
2017-03-24Merge branch 'jk/grep-no-index-fix' into maintLibravatar Junio C Hamano1-0/+66
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
2017-03-24Merge branch 'jn/remote-helpers-with-git-dir' into maintLibravatar Junio C Hamano2-0/+18
"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
2017-03-24tag: add tests for --with and --withoutLibravatar Ævar Arnfjörð Bjarmason1-2/+4
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>
2017-03-24ref-filter: add --no-contains option to tag/branch/for-each-refLibravatar Ævar Arnfjörð Bjarmason3-7/+193
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>
2017-03-24tag: change --point-at to default to HEADLibravatar Ævar Arnfjörð Bjarmason1-1/+8
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>
2017-03-24tag: implicitly supply --list given another list-like optionLibravatar Ævar Arnfjörð Bjarmason1-5/+50
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>
2017-03-24tag: change misleading --list <pattern> documentationLibravatar Ævar Arnfjörð Bjarmason1-0/+25
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>
2017-03-24tag: add more incompatibles mode testsLibravatar Ævar Arnfjörð Bjarmason1-0/+16
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>
2017-03-24name-hash: add test-lazy-init-name-hash to .gitignoreLibravatar Ramsay Jones1-0/+1
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24name-hash: add perf test for lazy_init_name_hashLibravatar Jeff Hostetler1-0/+19
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>
2017-03-24name-hash: add test-lazy-init-name-hashLibravatar Jeff Hostetler1-0/+264
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>
2017-03-24t7004, t7030: fix here-doc syntax errorsLibravatar Santiago Torres2-14/+10
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>
2017-03-23tests: lint for run-away here-docLibravatar Junio C Hamano1-3/+3
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>
2017-03-23completion: fill COMPREPLY directly when completing refsLibravatar SZEDER Gábor1-0/+27
__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>
2017-03-23completion: let 'for-each-ref' and 'ls-remote' filter matching refsLibravatar SZEDER Gábor1-0/+124
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>
2017-03-23completion: support excluding full refsLibravatar SZEDER Gábor1-0/+31
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>
2017-03-23completion: support completing fully qualified non-fast-forward refspecsLibravatar SZEDER Gábor1-0/+68
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>
2017-03-23completion: support completing full refs after '--option=refs/<TAB>'Libravatar SZEDER Gábor1-0/+31
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>
2017-03-23completion: wrap __git_refs() for better option parsingLibravatar SZEDER Gábor1-0/+106
__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>
2017-03-23tag tests: fix a typo in a test descriptionLibravatar Ævar Arnfjörð Bjarmason1-1/+1
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>
2017-03-23tag: remove a TODO item from the test suiteLibravatar Ævar Arnfjörð Bjarmason1-2/+0
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>