[macOS 14+] Unable to clone a repository that uses `git-lfs` about git-lfs

[bk2204]

Hey,

Do you have some sort of proxy on your system or network, including any sort of antivirus, non-default firewall, or monitoring software? The reason I ask is that I'm seeing an EOF when reading from the server, which typically indicates that the connection hung up, that it timed out, or otherwise wasn't successful in some way.

If you do have such software or proxy, can you try on a system or network (as appropriate) that doesn't have it and see if the problem reoccurs? If you don't, we can ask @chrisd8088, who does have a Mac (I don't), to poke around and verify that this works for him. I'm pretty sure it will, especially since we've tested this in CI, but there's always the possibility that something's broken.

[chrisd8088]

FWIW, I tried the following on macOS and had no problems (with Git LFS v3.4.1):

$ git clone https://gitlab.com/p2orN/lfs-test.git
$ cd lfs-test
$ git lfs ls-files
61bba855b5 * img.jpg

With GIT_CURL_VERBOSE=1 I see an HTTP request to fetch the Git LFS object:

GET https://gitlab.com/p2orN/lfs-test.git/gitlab-lfs/objects/61bba855b5cee3990a4ac2347a985509e6a4c5d4dd2bdcd4d543cbcf5abe5699

< HTTP/2.0 200 OK

That said, this is on macOS 13, not macOS 14.

[bk2204]

Hey,

The full error message I get here is this:

Error downloading object: sample.pdf (b167419): Smudge error: Error downloading sample.pdf (b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553): batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.

The part of the message after “batch response:” is what the server said: “This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.” That message comes from GitHub and means that the account owner has exceeded its bandwidth and they either need to purchase more data packs so that access will be restored or you'll need to wait until their usage resets (which will likely be at an unknown point in the next month).

This doesn't appear to be a malfunction in the open source Git LFS client, but rather that the client is simply reporting back what the server said when the operation failed, which is what it's supposed to be doing.

[p2or]

Hi @bk2204,

thank you. I assumed that the provided 'sandbox' would work and serve as a solid example as half of error message is the same, sorry my bad.

Unfortunately, the smudge error also occurs if the repo does not exceed its quota - Just created a new dedicated repository to play with and updated the steps to reproduce the behavior. Or would you rather prefer that I open up a new issue?

Thanks,
Christian

[bk2204]

Hey,

I don't see the same problem on my system. Can you please include the entire output (as a code block or an attached text file) of the command when running with GIT_TRACE=1 GIT_TRANSFER_TRACE=1 GIT_CURL_VERBOSE=1?

Here's what I get (with Git 2.43.2 and without the extra logging):

% git clone [email protected]:p2orN/lfs-test.git
Cloning into 'lfs-test'...
remote: Enumerating objects: 8, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 8 (delta 1), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (8/8), done.
Resolving deltas: 100% (1/1), done.

[p2or]

Hi @bk2204,

thank you for testing. Yeah, I can confirm that the provided repo works great on all other systems I've tested (debian, arch, win). On macOS, however, the main step to download the lfs data takes forever and finally aborts.

Can you please include the entire output?

Sure, with pleasure out.txt. If you need more info, please just let me know.

Thanks,
Christian

[p2or]

Hi folks,

I can confirm that the problem is on my end. I still can't believe it but the issue is caused by my router - when I establish a connection with another router, the actual pull works as expected. I will update this post as soon as I figure out what setting is causing this behavior.

Thanks to everyone who has taken the time and looked into this issue. @bk2204 thanks for putting me on the right track, @chrisd8088 thanks for your test, I really appreciate that.

Cheers,
Christian