14

I have two machines where git bash auto complete is agonizingly slow. When I hit tab, it can take 8 to 10 seconds for the filename to be completed. This only seems to happen when the auto complete is part of a git command. Auto complete for cd works fine. The actual execution of the git command runs fine.

I am using git version 1.8.3-preview20130601

$ git count-objects -vH
count: 9
size: 10.23 KiB
in-pack: 2488
packs: 1
size-pack: 18.68 MiB
prune-packable: 0
garbage: 0
size-garbage: 0 bytes

What could be causing this? Is there any possible fix?

EDIT: I updated to Git (version 1.8.4-preview20130916) and the problem still persists. I did notice that when running the bash shell in ConEmu the command displayed at the bottom during the long pause is uniq.exe. It seems that the call to that executable is what is chewing up the time.

EDIT: Updating to git version 1.9.0.msysgit.0 has alleviated much of the problem. The delay is now only 1 to 2 seconds. Other commands like cd are still almost instant (< 0.5s). I also do not see uniq.exe running anymore, just sh.exe.

MarcH
  • 18,738
  • 1
  • 30
  • 25
TwistedTech
  • 275
  • 4
  • 13

4 Answers4

5

I was still having an issue with slow autocomplete for git commands only, using version 1.9.5. Autocompleting at the root level could take 8 seconds, though it was faster at lower levels with fewer files.

I finally fixed the issue with information found here: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow

By setting git config core.fscache true for my repository, the autocomplete runs faster for many commands, like add and diff, though not all, such as rm. I hope that helps.

David Merriman
  • 6,056
  • 1
  • 18
  • 18
  • This yields a **significant** improvement when working with large (.git/ is 1.3G) repositories in git 2.7 on Windows 7. – piedar Sep 26 '16 at 18:00
  • While this may help on Windows, git-completion.bash is (was?) slow as hell on Linux too: https://stackoverflow.com/questions/9810327/git-tab-autocompletion-is-useless-can-i-turn-it-off-or-optimize-it – MarcH Oct 03 '17 at 17:54
5

Git 2.13 (Q2 2017) should improve Git bash completion, because 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.

See commit 227307a, commit 745d655, commit fef56eb, commit 400a755, commit 824388d, commit e8cb023, commit e896369, commit b2b6811, commit 3ad8ea7, commit aed3881, commit aa0644f, commit 2ea328a, commit 15b4a16 (23 Mar 2017), and commit c977eef (03 Feb 2017) by SZEDER Gábor (szeder).
(Merged by Junio C Hamano -- gitster -- in commit bf65060, 30 Mar 2017)

For example:

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().

Note: the performance of filename completion improves with Git 2.18 (Q2 2018): see "Git bash-completion with filename support?"

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I was seeing really slow autocomplete on windows 7, and it indeed seems much better after installing git 2.13. (Autocompleting branch names has gone from 30s to just a couple.) – starwed May 11 '17 at 15:02
4

This is a known issue with the stable version of ConEmu.

From the ConEmu page:

Disclaimer #2

If you notice lags while executing batches or commands (from cmd/git/bash/etc.) just upgrade to latest alpha build or uncheck option "Inject ConEmuHk". Read Issue 526 for details.

Darek Kay
  • 15,827
  • 7
  • 64
  • 61
alextercete
  • 4,871
  • 3
  • 22
  • 36
  • When I asked this question I hadn't used ConEmu yet. I discovered it afterward and noticed the exe name so I decided to include it. – TwistedTech May 22 '14 at 14:43
0

For me this was fixed by pruning the origin and removing already merged branches. Both are some git house keeping that should be done every once in a while anyway.

git remote update origin --prune

Explanation of the command below: Get all remote branches that are merged to origin/master | Black list | White list | Remove remote/origin prefix if applicable | Remove all remote/local branches.

WARNING: This will delete remote branches, use with causion.

git branch -a --merged origin/master | grep -v 'release' | grep 'remotes/origin/' | sed -e 's/remotes\/origin\///g' | xargs -t -n1 git push -d origin

WARNING: This will remove local branches.

git branch --merged origin/master | grep -v 'release' | grep 'feature' | xargs -t -n1 git branch -d
Daan
  • 127
  • 4