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()
"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
This is the endgame of the topic to avoid blindly falling back to
".git" when the setup sequence said we are _not_ in Git repository.
A corner case that happens to work right now may be broken by a
call to die("BUG").
* jk/no-looking-at-dotgit-outside-repo-final:
setup_git_env: avoid blind fall-back to ".git"
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
* jc/merge-drop-old-syntax:
merge: drop 'git merge <message> HEAD <commit>' syntax
sha1dc/sha1.c wanted to check the endianness of the target platform
at compilation time and used a CPP macro with a rather overly
generic name, "BIGENDIAN", to pass the result of the check around
in the file. It wasn't prepared for the same macro set to 0
(false) by the platform to signal that the target is _not_ a big
endian box, and assumed that the endianness detection logic it has
alone would be the one that is setting the macro, resulting in a
breakage on Windows. This has been fixed by using a bit less
generic name for the same purpose.
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
* jk/fast-import-cleanup:
pack.h: define largest possible encoded object size
encode_in_pack_object_header: respect output buffer length
fast-import: use xsnprintf for formatting headers
fast-import: use xsnprintf for writing sha1s
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
"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
* jk/pack-name-cleanups:
index-pack: make pointer-alias fallbacks safer
replace snprintf with odb_pack_name()
odb_pack_keep(): stop generating keepfile name
sha1_file.c: make pack-name helper globally accessible
move odb_* declarations out of git-compat-util.h
* jk/rev-parse-cleanup:
rev-parse: simplify parsing of ref options
rev-parse: add helper for parsing "--foo/--foo="
rev-parse: use skip_prefix when parsing options
Merge branch 'ew/http-alternates-as-redirects-warning' into maint
Recent versions of Git treats http alternates (used in dumb http
transport) just like HTTP redirects and requires the client to
enable following it, due to security concerns. But we forgot to
give a warning when we decide not to honor the alternates.
* ew/http-alternates-as-redirects-warning:
http: release strbuf on disabled alternates
http: inform about alternates-as-redirects behavior
Merge branch 'dp/filter-branch-prune-empty' into maint
"git filter-branch --prune-empty" drops a single-parent commit that
becomes a no-op, but did not drop a root commit whose tree is empty.
* dp/filter-branch-prune-empty:
p7000: add test for filter-branch with --prune-empty
filter-branch: fix --prune-empty on parentless commits
t7003: ensure --prune-empty removes entire branch when applicable
t7003: ensure --prune-empty can prune root commit
Merge branch 'mm/fetch-show-error-message-on-unadvertised-object' into maint
"git fetch" that requests a commit by object name, when the other
side does not allow such an request, failed without much
explanation.
* mm/fetch-show-error-message-on-unadvertised-object:
fetch-pack: add specific error for fetching an unadvertised object
fetch_refs_via_pack: call report_unmatched_refs
fetch-pack: move code to report unmatched refs to a function
Merge branch 'jk/interpret-branch-name' into maint
"git branch @" created refs/heads/@ as a branch, and in general the
code that handled @{-1} and @{upstream} was a bit too loose in
disambiguating.
* jk/interpret-branch-name:
checkout: restrict @-expansions when finding branch
strbuf_check_ref_format(): expand only local branches
branch: restrict @-expansions when deleting
t3204: test git-branch @-expansion corner cases
interpret_branch_name: allow callers to restrict expansions
strbuf_branchname: add docstring
strbuf_branchname: drop return value
interpret_branch_name: move docstring to header file
interpret_branch_name(): handle auto-namelen for @{-1}
A few tests were run conditionally under (rare) conditions where
they cannot be run (like running cvs tests under 'root' account).
* ab/cond-skip-tests:
gitweb tests: skip tests when we don't have Time::HiRes
gitweb tests: change confusing "skip_all" phrasing
cvs tests: skip tests that call "cvs commit" when running as root
user.email that consists of only cruft chars should consistently
error out, but didn't.
* jk/ident-empty:
ident: do not ignore empty config name/email
ident: reject all-crud ident name
ident: handle NULL email when complaining of empty name
ident: mark error messages for translation
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 '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
"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
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
* 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
* 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
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>
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
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
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
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 '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>
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>
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>
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>
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>
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>
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>
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>
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
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
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>
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>
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.
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>
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>