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.
Related
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?
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
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.
I have a Heroku project that has worked for months with no issues relating to git cloning, pushing, or pulling. Recently, I started getting this error when performing a git pull:
remote: Counting objects: 729, done.
remote: Compressing objects: 100% (308/308), done.
fatal: The remote end hung up unexpectedlyKiB | 76 KiB/s
fatal: early EOF
fatal: index-pack failed
There has been no significant changes to the code base. I am well under the storage limit on Heroku. A coworker of mine also cannot do a git clone of the heroku repository. It results in the same error. I have noticed that the early EOF line sometimes also includes this:
fatal: early EOFs: 24% (153/637), 196.00 KiB | 117 KiB/s
I am on a Mac OS X Mountain Lion Macbook Air, with the native server being utilized, and no other deep customizations that would impact the system.
Any ideas?
Well, I have heard several say that Heroku is not a reliable repository platform, so I am taking that to heart, and moved my repository on over to BitBucket. That solved my problem. From now on all other repositories I create will be hosted there, and still deployed on Heroku.
Here's a workaround:
"Edit local .git/config"
Add compression = 0 to the [core] section.
Other solution:
Run git config --add core.compression -1 from the terminal.
Tried this several times including nuking the previous download and manually getting the submodule. Does anyone have a workaround?
SilverFir-2:SRC mike$ sudo ./git-flow-installer
### gitflow no-make installer ###
Installing git-flow to /usr/local/bin
Cloning repo from GitHub to gitflow
Cloning into 'gitflow'...
remote: Counting objects: 1407, done.
remote: Compressing objects: 100% (602/602), done.
remote: Total 1407 (delta 893), reused 1285 (delta 790)
Receiving objects: 100% (1407/1407), 358.18 KiB | 121 KiB/s, done.
Resolving deltas: 100% (893/893), done.
Updating submodules
Submodule 'shFlags' (git://github.com/nvie/shFlags.git) registered for path 'shFlags'
Cloning into 'shFlags'...
fatal: unable to connect to github.com:
github.com[0: 204.232.175.90]: errno=Operation timed out
Clone of 'git://github.com/nvie/shFlags.git' into submodule path 'shFlags' failed
install: gitflow/git-flow -> /usr/local/bin/git-flow
install: gitflow/git-flow-init -> /usr/local/bin/git-flow-init
install: gitflow/git-flow-feature -> /usr/local/bin/git-flow-feature
install: gitflow/git-flow-hotfix -> /usr/local/bin/git-flow-hotfix
install: gitflow/git-flow-release -> /usr/local/bin/git-flow-release
install: gitflow/git-flow-support -> /usr/local/bin/git-flow-support
install: gitflow/git-flow-version -> /usr/local/bin/git-flow-version
install: gitflow/gitflow-common -> /usr/local/bin/gitflow-common
install: gitflow/gitflow-shFlags: No such file or directory
SilverFir-2:SRC mike$
It looks like it may just be a temporary connection issue (though it's unusual that you were able to manually get the submodule but the script couldn't do it). The make-less installer appeared to work fine on my Mac OS 10.8.3 system. The make-less installer isn't doing much, you can run the steps yourself to install it-
git clone https://github.com/nvie/gitflow.git
cd gitflow
git submodule init
git submodule update
sudo make install