0

Reference to this post:

Git clone over Bitbucket takes a long time even when cloning from an empty orphan branch

I used this command:

git clone repo_url . --branch some/big/master/branch --single-branch

I am trying to clone one single branch but this time, not an empty branch, it is one of the relatively big branches with many large ZIP files with the LFS feature turned on.

The cloning process seemed to work fine, but it froze for more than one hour.

Then, I pressed ctrl-x or ctrl-c to break the process, and used this command:

git fetch
git reset --hard origin/some/big/branch

It starts doing something, then it will freeze again for what looks like forever.

Any idea what is going on?

Update 1

I then closed all windows, restarted the laptop, and tried again, and it finished in 30 seconds.

Is this probably because git needs a lot of resources to clone LFS files? I have pushed a good number of ZIP files with LFS turned on.

Update 2:

I did another round of tests with and without the --single-branch switch. I noticed that running the clone from another colleague's laptop, with the single branch switch, is faster than without the single branch switch and it took a max of 10 seconds to complete in both cases. But, from my laptop, it took 5 minutes to complete without the single branch switch I checked Task Manager and didn't find any reference to GIT-LFS. I ran the cloning process on my laptop with the single branch switch, and it finished in 10 seconds.

So the problem is really cloning any repo without using the single branch switch, and it is on my laptop.

This means the problem is either in my laptop resources or some config that allows git to run and exploit the available resources.

Is there some config to let git run more efficiently?

enter image description here

tarekahf
  • 738
  • 1
  • 16
  • 42
  • The clone is freezing because other git commands on other folders are working fine. Mind you that I am using Bitbucket. – tarekahf Aug 23 '22 at 07:02
  • Actually, the last command `git reset --hard ...` I mentioned above is now finished. It took like an hour or so. I am just wondering why it took several hours to complete the process which is git clone and git reset. – tarekahf Aug 23 '22 at 07:42
  • Can you please explain how to check what is running from another terminal? – tarekahf Aug 23 '22 at 07:43
  • I am not afraid, and that is why I am asking here. Is this the same as the task manager in Windows? So when this happens next time, I will check if GIT-LFS is running. Is that what you mean? – tarekahf Aug 24 '22 at 14:14
  • I did another round of tests with and without `--single-branch` switch. I noticed that running the clone from another colleague's laptop, with the single branch switch, is faster than without the single branch switch and it took a max of 10 seconds to complete in both cases. But, from my laptop, it took 5 minutes to complete without the single branch switch I checked Task Manager and didn't find any reference to GIT-LFS. So it's either laptop resources or some config that allows `git` to run and exploit the available resources. – tarekahf Aug 30 '22 at 04:20
  • I found the answer. Check the last post. – tarekahf Aug 30 '22 at 04:49

2 Answers2

3

LFS is not part of Git. It is an extension / wrapper system. It works by tricking Git: Git stores only "pointer files". The "large" files—they don't actually have to be large, just taken-over by the wrapper, but there's usually no point in having it take over small files—are moved out to some area where Git cannot get its grubby little protuberances on them.

When you push or fetch to/from a Git server, Git transfers commits that contain only the pointer files. If you clone an LFS-wrapped repository using plain Git, you will see the pointer files.

If you have LFS installed, however, LFS will insert itself into the process. First, Git will clone the repository—thereby obtaining commits containing the pointer files—and then as Git goes to check out the commits, LFS will spring (very slowly) into action, obtaining the real files from the LFS server. This is a completely separate server. This takes as long as it takes! When the LFS code is finished getting the real files from the LFS server, then LFS allows Git to proceed.

You're not waiting for Git. You're waiting for Git-LFS.

(Note that LFS stores its files outside Git, and obtains files progressively, so if you've tried to clone and interrupted it, you've probably gotten some of the files. If you tried again—or tried fetching—and interrupted that, you've probably now downloaded more of the files. Eventually, you get all of the files. Where and how Git-LFS stores the large files is up to Git-LFS: Git has no hand in this.)

Use the tag for questions about Git-LFS. (Do not use the tag, which is for Linux-from-Scratch.)

torek
  • 448,244
  • 59
  • 642
  • 775
  • I found the answer, check it out. – tarekahf Aug 30 '22 at 04:50
  • LFS makes its own https connections. I don't know if it uses the same proxy as Git but [this question](https://stackoverflow.com/q/51756409/1256452) says that it will by default. Presumably your proxy is the problem here and you want to disable it for *at least* LFS; whether you want it for Git itself is another question entirely. – torek Aug 30 '22 at 04:55
0

The problem was that I set a proxy. In the early days I set up git, I think it didn't work unless I used a proxy, then somehow, this restriction is no longer required.

I used the following command:

git config --global --list
# http.proxy setting was found
git config --global --unset http.proxy

Now, the clone is faster than ever.

tarekahf
  • 738
  • 1
  • 16
  • 42