54

Note I have studied the git-is-very-very-slow question, but in their case the reason was big binary files - while in my repository there is PHP/JS/HTML/CSS only code (no binaries) and the biggest file in the repository is around 800 KB.

I've changed one file (a few lines), then git add . and git commit -m "msg", then git push origin master.

On some other machine, when I do git pull origin master it downloads a few MiB of data, and it takes more than 2 minutes to calculate the delta and apply changes. Something is terribly wrong here.

I suspect some recent operations may cause this:

recently, I've accidentally added many vendor assets (bower_components assets) when I realized it, I've used git rm to remove them from repository (and ofcourse, git add, git commit and git push to upstream).

That was a few days ago and the problems I have right now started happeing around that time.

I have two questions:

  • Why this is happeing?
  • How can I fix my repository?

Note: I am the only one useing and pushing to this repo.

simhumileco
  • 31,877
  • 16
  • 137
  • 115
ioleo
  • 4,697
  • 6
  • 48
  • 60
  • 2
    try `git ls-files` to view all files checked into git. May give an idea of what's happening – Akash Feb 26 '14 at 11:47
  • there is 530 files total.. I've reviewed the list, and all of them should be there (and none of them is bigger than 800KB) – ioleo Feb 26 '14 at 12:13
  • 1
    Did the other machine already have the changes where you removed the vendor assets? If not, it may have needed to pull in the revisions where they were added and deleted, since just `git rm`ing them leaves the additions in the history. Does it remain slow if you do a subsequent pull of new changes? – Wooble Feb 26 '14 at 12:17
  • after accidentally adding files, I did a pull on target machine... this is when I realized my mistake.. so I went to my source machine, did `git rm`, pushed upstream, and then went back to my target machine and pulled – ioleo Feb 26 '14 at 12:21
  • however, ever since that moment, every subsequent pull on target machine has been slow... I understand that it had to download the files the first time it pulled that commit.. but I would expect it to work fast on all subsequenst pulls (regardless of me doing or not the `git rm`) – ioleo Feb 26 '14 at 12:22
  • PS. all changes are made on Source machine, then pushed to VersionControl server, and then pulled on Target machines --> only the pulls on Target machine are slow, pushes work fast – ioleo Feb 26 '14 at 12:23

8 Answers8

46

I had the same issue. For me this was a IPv4/IPv6 issue. I fixed it forcing SSH to use IPv4.

Set "AddressFamily inet" in /etc/ssh/ssh_config to force IPv4 connection. Then restart ssh client sudo service ssh restart

More info here.

JGL
  • 766
  • 1
  • 7
  • 16
  • 18
    This is the solution!! I finally solved the problem by this. You could try `git fetch -4` or `git push -4` to see if actually solves the problem before you add it to ssh_config. – Arst Dec 11 '20 at 03:42
  • 2
    @Arst what does `git fetch -4` means? – kajibu Dec 30 '20 at 04:56
  • 3
    @kajibu it means using IPv4. can be either -4, --ipv4. for IPv6: -6 --ipv6. – Arst Jan 04 '21 at 06:09
  • 1
    This solution worked for me. But there is no need for a service restart. – twan163 Aug 09 '21 at 17:32
  • @Arst solution saved me so much pain. No need to restart – anysite Sep 29 '21 at 20:42
  • In my case git had been working just fine. I was running on a Raspberry Pi 4 and then one day it starts taking forever. I'm ssh'ing in from a LInux box to the Pi maybe there was an update to SSH on Linux that caused it, but thanks for the answer. – David Bradley Apr 21 '22 at 23:30
17

I have had the same issue when I was dealing with thousands of small files. The thing that fixed it for me was to set the postbuffer in git repo's config

git config http.postBuffer 524288000

Instead of uploading with 18KB/s it suddenly went the full bandwidth

Sander Stad
  • 246
  • 4
  • 8
12

I tried all solutions in this thread with no luck. I tried using git protocol 2 at the suggestion of a coworker, which ended up being very effective (went from waiting 3 minutes for pulls/pushes to start to a few seconds)

git config --global protocol.version 2
Eli Berkowitz
  • 299
  • 3
  • 12
5

The problem was in EmberJS app directory. It contained node_modules and bower_components directories which kept third-party libraries used by GruntJS to build my JS and CSS assets.

Each of these contained many files and directories.. considering that the dependency tree contained hundreds of libraries of size varying from small (few files) to big fat (many files).

After removing these directories and ignoring them, the git repository works fast again.

Dariusz Woźniak
  • 9,640
  • 6
  • 60
  • 73
ioleo
  • 4,697
  • 6
  • 48
  • 60
5

I had a similar experience -- git pull and push suddenly starting to run EXTREMELY slowly, taking ten minutes or more, both on my local Mac OSX and on my Linux / Apache server. I deleted the local copy of the repo on my Mac, and recloned it, and it started to run fine. Did the same thing on the server, and all is well. I suppose it was somehow corrupted?

NessBird
  • 745
  • 1
  • 6
  • 15
3

Just incase if someone is stumble upon this thread, before deleting your .git folder, try to restart your wifi, that may be just your wifi connection issue.

ATHER
  • 3,254
  • 5
  • 40
  • 63
2

Not only the protocol v2 will help, but the commit graph (mentioned here) will help too.

With Git 2.34 (Q4 2021), loading of ref tips to prepare for common ancestry negotiation in "git fetch-pack"(man) has been optimized by taking advantage of the commit graph when available.

See commit 3e5e6c6 (04 Aug 2021) by Patrick Steinhardt (pks-t).
(Merged by Junio C Hamano -- gitster -- in commit 1b2be06, 24 Aug 2021)

fetch-pack: speed up loading of refs via commit graph

Signed-off-by: Patrick Steinhardt

When doing reference negotiation, git-fetch-pack(1) is loading all refs from disk in order to determine which commits it has in common with the remote repository.
This can be quite expensive in repositories with many references though: in a real-world repository with around 2.2 million refs, fetching a single commit by its ID takes around 44 seconds.

Dominating the loading time is decompression and parsing of the objects which are referenced by commits.
Given the fact that we only care about commits (or tags which can be peeled to one) in this context, there is thus an easy performance win by switching the parsing logic to make use of the commit graph in case we have one available.
Like this, we avoid hitting the object database to parse these commits but instead only load them from the commit-graph.
This results in a significant performance boost when executing git-fetch(man) in said repository with 2.2 million refs:

Benchmark #1: HEAD~: git fetch $remote $commit
  Time (mean ± σ):     44.168 s ±  0.341 s    [User: 42.985 s, System: 1.106 s]
  Range (min … max):   43.565 s … 44.577 s    10 runs

Benchmark #2: HEAD: git fetch $remote $commit
  Time (mean ± σ):     19.498 s ±  0.724 s    [User: 18.751 s, System: 0.690 s]
  Range (min … max):   18.629 s … 20.454 s    10 runs

Summary
  'HEAD: git fetch $remote $commit' ran
    2.27 ± 0.09 times faster than 'HEAD~: git fetch $remote $commit'
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

I was using Linux Mint and GitLab and GitHub. I had no problems with pull/fetch before, but suddenly I only had problems with GitLab. After reading this thread, I understood that it might be related to SSH and IPv4/6.

When I saw on https://whatismyipaddress.com/ that the website could not find my IPv6 address, I restarted my router. Now everything is fine.

so before you start changing setting try this simple solution

Shlomi Yahbes
  • 21
  • 3