git-commit-vandalism

History

SZEDER Gábor a31e62629a completion: optimize refs completion After a unique command or option is completed, in most cases it is a good thing to add a trailing a space, but sometimes it doesn't make sense, e.g. when the completed word is an option taking an argument ('--option=') or a configuration section ('core.'). Therefore the completion script uses the '-o nospace' option to prevent bash from automatically appending a space to unique completions, and it has the __gitcomp() function to add that trailing space only when necessary. See `72e5e989` (bash: Add space after unique command name is completed., 2007-02-04), `78d4d6a2` (bash: Support unique completion on git-config., 2007-02-04), and `b3391775` (bash: Support unique completion when possible., 2007-02-04). __gitcomp() therefore iterates over all possible completion words it got as argument, and checks each word whether a trailing space is necessary or not. This is ok for commands, options, etc., i.e. when the number of words is relatively small, but can be noticeably slow for large number of refs. However, while options might or might not need that trailing space, refs are always handled uniformly and always get that trailing space (or a trailing '.' for 'git config branch.<head>.'). Since refs listed by __git_refs() & co. are separated by newline, this allows us some optimizations with 'compgen'. So, add a specialized variant of __gitcomp() that only deals with possible completion words separated by a newline and uniformly appends the trailing space to all words using 'compgen -S " "' (or any other suffix, if specified), so no iteration over all words is needed. But we need to fiddle with IFS, because the default IFS containing a space would cause the added space suffix to be stripped off when compgen's output is stored in the COMPREPLY array. Therefore we use only newline as IFS, hence the requirement for the newline-separated possible completion words. Convert all callsites of __gitcomp() where it's called with refs, i.e. when it gets the output of either __git_refs(), __git_heads(), __git_tags(), __git_refs2(), __git_refs_remotes(), or the odd 'git for-each-ref' somewhere in _git_config(). Also convert callsites where it gets other uniformly handled newline separated word lists, i.e. either remotes from __git_remotes(), names of set configuration variables from __git_config_get_set_variables(), stashes, or commands. Here are some timing results for dealing with 10000 refs. Before: $ refs="$(__git_refs ~/tmp/git/repo-with-10k-refs/)" $ time __gitcomp "$refs" real 0m1.134s user 0m1.060s sys 0m0.130s After: $ time __gitcomp_nl "$refs" real 0m0.373s user 0m0.360s sys 0m0.020s Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>		2011-10-21 14:38:22 -07:00
..
blameview	War on whitespace	2007-06-07 00:04:01 -07:00
buildsystems	msvc: Fix an "unrecognized option" linker warning	2010-01-22 16:15:14 -08:00
ciabot	contrib/ciabot: git-describe commit instead of HEAD	2010-10-29 14:09:48 -07:00
completion	completion: optimize refs completion	2011-10-21 14:38:22 -07:00
continuous	contrib/continuous: a continuous integration build manager	2007-03-19 22:21:19 -07:00
convert-objects	Documentation: use [verse] for SYNOPSIS sections	2011-07-06 14:26:26 -07:00
emacs	git.el: Don't use font-lock-compile-keywords	2011-04-03 11:08:54 -07:00
examples	cherry-pick/revert: add support for -X/--strategy-option	2010-12-28 11:27:56 -08:00
fast-import	git-p4: Allow branch definition with git config	2011-08-22 21:08:37 -07:00
git-shell-commands	Add sample commands for git-shell	2010-08-12 15:16:31 -07:00
gitview	Documentation: use [verse] for SYNOPSIS sections	2011-07-06 14:26:26 -07:00
hg-to-git	Correct references to /usr/bin/python which does not exist on FreeBSD	2010-03-24 14:33:54 -07:00
hooks	contrib/hooks: adapt comment about Debian install location for contrib hooks	2011-09-26 16:39:34 -07:00
mw-to-git	git-remote-mediawiki: allow a domain to be set for authentication	2011-09-28 15:20:23 -07:00
p4import	Correct references to /usr/bin/python which does not exist on FreeBSD	2010-03-24 14:33:54 -07:00
patches	INSTALL: add warning on docbook-xsl 1.72 and 1.73	2007-08-04 01:55:08 -07:00
stats	contrib: update packinfo.pl to not use dashed commands	2008-10-18 06:20:27 -07:00
svn-fe	Documentation: use [verse] for SYNOPSIS sections	2011-07-06 14:26:26 -07:00
thunderbird-patch-inline	contrib/thunderbird-patch-inline: do not require bash to run the script	2011-03-30 12:29:39 -07:00
vim	contrib/vim: change URL to point to the latest syntax files	2009-01-12 23:36:03 -08:00
workdir	prefer test -h over test -L in shell scripts	2010-09-27 10:48:23 -07:00
git-resurrect.sh	request-pull: protect against OPTIONS_KEEPDASHDASH from environment	2010-05-01 11:02:21 -07:00
README	War on whitespace	2007-06-07 00:04:01 -07:00
remotes2config.sh	contrib: Make remotes2config.sh script more robust	2007-12-04 14:35:08 -08:00
rerere-train.sh	Add contrib/rerere-train script	2008-09-29 09:15:41 -07:00

README

Contributed Software

Although these pieces are available as part of the official git
source tree, they are in somewhat different status.  The
intention is to keep interesting tools around git here, maybe
even experimental ones, to give users an easier access to them,
and to give tools wider exposure, so that they can be improved
faster.

I am not expecting to touch these myself that much.  As far as
my day-to-day operation is concerned, these subdirectories are
owned by their respective primary authors.  I am willing to help
if users of these components and the contrib/ subtree "owners"
have technical/design issues to resolve, but the initiative to
fix and/or enhance things _must_ be on the side of the subtree
owners.  IOW, I won't be actively looking for bugs and rooms for
enhancements in them as the git maintainer -- I may only do so
just as one of the users when I want to scratch my own itch.  If
you have patches to things in contrib/ area, the patch should be
first sent to the primary author, and then the primary author
should ack and forward it to me (git pull request is nicer).
This is the same way as how I have been treating gitk, and to a
lesser degree various foreign SCM interfaces, so you know the
drill.

I expect that things that start their life in the contrib/ area
to graduate out of contrib/ once they mature, either by becoming
projects on their own, or moving to the toplevel directory.  On
the other hand, I expect I'll be proposing removal of disused
and inactive ones from time to time.

If you have new things to add to this area, please first propose
it on the git mailing list, and after a list discussion proves
there are some general interests (it does not have to be a
list-wide consensus for a tool targeted to a relatively narrow
audience -- for example I do not work with projects whose
upstream is svn, so I have no use for git-svn myself, but it is
of general interest for people who need to interoperate with SVN
repositories in a way git-svn works better than git-svnimport),
submit a patch to create a subdirectory of contrib/ and put your
stuff there.

-jc