mirror of
https://github.com/git/git
synced 2024-10-12 11:32:34 +00:00
b2b6811451
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> |
||
---|---|---|
.. | ||
buildsystems | ||
coccinelle | ||
completion | ||
contacts | ||
credential | ||
diff-highlight | ||
emacs | ||
examples | ||
fast-import | ||
git-jump | ||
git-shell-commands | ||
hg-to-git | ||
hooks | ||
long-running-filter | ||
mw-to-git | ||
persistent-https | ||
remote-helpers | ||
stats | ||
subtree | ||
svn-fe | ||
thunderbird-patch-inline | ||
update-unicode | ||
workdir | ||
convert-grafts-to-replace-refs.sh | ||
git-resurrect.sh | ||
README | ||
remotes2config.sh | ||
rerere-train.sh |
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