My repo uses git lfs. For a fresh clone, I ran:
git lfs install
git clone https://example.com/repo.git
The clone gets to the point where it starts downloading lfs files, gets to some file and then fails. The file at which it fails is different each time I attempt to clone. Very occasionally it succeeds.
Here is the output:
Cloning into 'repo'...
remote: Counting objects: 35699, done.
remote: Compressing objects: 100% (17678/17678), done.
remote: Total 35699 (delta 15603), reused 35553 (delta 15545)
Receiving objects: 100% (35699/35699), 231.45 MiB | 11.12 MiB/s, done.
Resolving deltas: 100% (15603/15603), done.
Downloading big_file.big (157.39 KB)
...
Downloading some_other_big_file.big (18.84 KB)
Error downloading object: some_other_big_file.big
Errors logged to blah.log
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: some_other_big_file.big: smudge filter lfs failed
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'
The lfs logs say:
Error downloading object: some_other_big_file.big
Smudge error: Error buffering media file: cannot write data to tempfile "blah.tmp": LFS: unexpected EOF:
github.com/git-lfs/git-lfs/errors.newWrappedError
C:/Go/src/github.com/git-lfs/git-lfs/errors/types.go:166
github.com/git-lfs/git-lfs/errors.NewSmudgeError
C:/Go/src/github.com/git-lfs/git-lfs/errors/types.go:252
github.com/git-lfs/git-lfs/lfs.PointerSmudge
C:/Go/src/github.com/git-lfs/git-lfs/lfs/pointer_smudge.go:70
github.com/git-lfs/git-lfs/lfs.(*Pointer).Smudge
C:/Go/src/github.com/git-lfs/git-lfs/lfs/pointer.go:65
github.com/git-lfs/git-lfs/commands.smudge
C:/Go/src/github.com/git-lfs/git-lfs/commands/command_smudge.go:84
github.com/git-lfs/git-lfs/commands.filterCommand
C:/Go/src/github.com/git-lfs/git-lfs/commands/command_filter_process.go:65
github.com/git-lfs/git-lfs/vendor/github.com/spf13/cobra.(*Command).execute
C:/Go/src/github.com/git-lfs/git-lfs/vendor/github.com/spf13/cobra/command.go:477
github.com/git-lfs/git-lfs/vendor/github.com/spf13/cobra.(*Command).Execute
C:/Go/src/github.com/git-lfs/git-lfs/vendor/github.com/spf13/cobra/command.go:551
github.com/git-lfs/git-lfs/commands.Run
C:/Go/src/github.com/git-lfs/git-lfs/commands/run.go:66
main.main
C:/Go/src/github.com/git-lfs/git-lfs/git-lfs.go:33
runtime.main
C:/Go/src/runtime/proc.go:183
runtime.goexit
C:/Go/src/runtime/asm_amd64.s:2086
If I try git lfs pull at this point, everything works fine.
Any idea what could be causing this failure to download the lfs files?
I had the similar issue and there was already a bug reported with git lfs. While the bug was being resolved, this workaround helped me, where you skip the filter where it was failing.
// Skip smudge - We'll download binary files later in a faster batch
git lfs install --skip-smudge
// Do git clone here
git clone ...
// Fetch all the binary files in the new clone
git lfs pull
// Reinstate smudge
git lfs install --force
Credits: #strich
Try to do git lfs pull from GitBash.
It looks like the commandprompt isn't showing pass key popup, which is necessary for git lfs to work.
Git config settings
git config --global http.sslVerify true
git config --global http.sslBackend schannel
This worked for me
Related
I'm trying to clone a repository on Gitlab with the command:
git clone git#gitlab.com:company/folder/project.git
And every time I get this output:
remote: Enumerating objects: 3860, done.
remote: Counting objects: 100% (482/482), done.
remote: Compressing objects: 100% (360/360), done.
fatal: pack has bad object at offset 152904485: inflate returned 1
fatal: fetch-pack: invalid index-pack output
The thing is, it happens only on my machine, I tested the exact same command accessing a linux machine remotely through ssh and it works just fine. Also, it's relevant to mention that I'm using git on Windows 11. How can I solve this?
As in this thread, start checking the protocol used:
git -c protocol.version=1 git#gitlab.com:company/folder/project.git
As bit as in this gist, you could try an incremental clone, using a shallow clone (--depth)
REPO=$1
DIR=$2
git clone --recurse-submodules $REPO $DIR --depth=1
cd $DIR
git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
git fetch --depth=10
git fetch --depth=100
...
Another approach, clone up to the problematic commit: (--shallow-exclude=<revision>)
git clone --shallow-exclude=anOlCommit
There is a patch in progress around index-pack (June 2022), about unpacking large object in a stream.
The OP Otávio Augusto Silva confirms in the comments:
It didn't worked on Windows 11 cmd but it worked on WSL2 (Ubuntu)
And since Git can be installed on Windows AND on WSL, that could be a valid workaround.
I've cloned this repo, but two of the files have an asterisk * in their names which is a disallowed character for Windows filenames. This means the repo clones but fails to checkout. Cloning looks like this:
> git clone https://github.com/mallowigi/iconGenerator.git
Cloning into 'iconGenerator'...
remote: Enumerating objects: 2592, done.
remote: Counting objects: 100% (2592/2592), done.
remote: Compressing objects: 100% (1545/1545), done.
remote: Total 2592 (delta 1232), reused 2383 (delta 1037), pack-reused 0R
Receiving objects: 100% (2592/2592), 14.87 MiB | 7.26 MiB/s, done.
Resolving deltas: 100% (1232/1232), done.
# hits error here
error: invalid path 'examples/files/*.pyc'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'
When I try git restore --source=HEAD . I get this error:
> git restore --source=HEAD .
error: invalid path 'examples/files/*.pyc'
error: invalid path 'examples/files/*.pyo'
I could go through manually and restore all the folders except examples/files/, but my question is: Is there a way to do this with one command? Maybe something like:
> git restore --source=HEAD . --except=/examples/files/*
As per evolutionxbox's comment the solution was just to do
git checkout HEAD -- .
This de-stages the deletion of all the other files and leaves a git status of:
On branch master
Your branch is up to date with 'origin/master'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
deleted: examples/files/*.pyc
deleted: examples/files/*.pyo
I can clone a particular repository with cmd.exe without problems but it fails with PowerShell.
Git Version: 2.27.0.windows.1
Required certificates were added to git install dir\mingw64\ssl\certs\ca-bundle.crt
PowerShell Error
PS D:\git> git clone https://foo/bar.git
Cloning into 'foobar'...
remote: Enumerating objects: 1352, done.
remote: Counting objects: 100% (1352/1352), done.
remote: Compressing objects: 100% (1016/1016), done.
error: RPC failed; curl 56 Malformed encoding found in chunked-encoding
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
Snippets from my .gitconfig
I already added the following properties after googling for the problem:
file:C:/users/doej1/.gitconfig core.longpaths=true
file:C:/users/doej1/.gitconfig core.autocrlf=true
file:C:/users/doej1/.gitconfig http.postbuffer=524288000
Why does it work with cmd.exe but not with PowerShell?
I try to checkout repository on Windows 7 machine with git.exe:
C:/tmp>git --version
git version 2.12.0.windows.1
C:/tmp>git clone https://someuser#bitbucket.org/somcomp/someproj.git
Cloning into 'somproj'...
remote: Counting objects: 11762, done.
remote: Compressing objects: 100% (7028/7028), done.
Receiving objects: 100% (11762/11762), 48.36 MiB | 1.30 MiB/s, done.
remote: Total 11762 (delta 5706), reused 10135 (delta 4230)
Resolving deltas: 100% (5706/5706), done.
fatal: cannot create directory at 'someproj/node_modules/console-stamp/node_modules/dateformat/node_modules/meow/node_modules/normalize-package-data/node_modules/validate-npm-package-license/node_modules/spdx-correct/node_modules': No such file or directory
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'
C:\tmp>git status
fatal: Not a git repository (or any of the parent directories): .git
What can I do here? I tried git config --system core.longpaths true advice, but it doesn't help. Any other recipes? Failed folder doesn't seem to contain any ugly characters if I look at it in bitbucket and has only one child folder:
node_modules / console-stamp / node_modules / dateformat / node_modules / meow / node_modules / normalize-package-data / node_modules / validate-npm-package-license / node_modules / spdx-correct / node_modules / spdx-license-ids /
Thanx for any ideas.
Upgrading to git version 2.12.2.windows.2 solved the problem for me, since this bug was fixed only recently.
I'm using Windows 8, 64bit - I recently installed Git to use it on this computer. However, it is not possible to clone any repository. It exits with the message:
$ git clone ssh://me#some.address.com/some/git/repository.git
Cloning into 'repository'...
error: Unable to create c:/Users/Danyel/workspace/repository/.git/HEAD
When I open cmd as Administrator and try the same command, it succeeds (cmd as normal user fails just like with Git Bash):
C:\Users\Danyel\workspace>git clone ssh://me#some.address.com/some/git/repository.git
Cloning into 'repository'...
remote: Counting objects: 221, done.
remote: Compressing objects: 100% (195/195), done.
remote: Total 221 (delta 34), reused 167 (delta 15)
Receiving objects: 100% (221/221), 9.23 MiB | 1.38 MiB/s, done.
Resolving deltas: 100% (34/34), done.
Checking connectivity... done
I'm using this version of Git: Git-1.8.4-preview20130916
Any help or clues are welcome! I have checked for the permissions and have ownership in parent folders ("repository", ".git"). What else can it be??
Edit:
The GIT_TRACE option did not give any clue about it either:
$ GIT_TRACE=2 git clone ssh://me#some.address.com/some/git/repository.git
trace: built-in: git 'clone' 'ssh://me#some.address.com/some/git/repository.git'
Cloning into 'repository'...
error: Unable to create c:/Users/Danyel/Desktop/repository/.git/HEAD
As illustrated in this thread, that kind of error message only happens when one of the parent folders is a symlink.
Check if you can clone it in another path (C:\ or C:/Users/Danyel).
But I suspect that Desktop\workspace is a symlink, and as such, not very compatible with a cloned repo path (because that would un-symlink that path, which might not be compatible with other apps/process using that same path).
The only other instance of that issue is related to a path-length limit.