2

I'm having trouble with switching my local SugarCRM instance from a gitlab repo to a new github repo. Locally, the project is on a vagrant VM running on a Windows 10 host. I run git commands from the host machine. I created a new private github repo, set it as the new remote, and generated a new public/private ssh key pair on the host machine in C:\Users\.ssh. When I try to push the project to the remote repo for the first time, I get 

Enumerating objects: 58649, done.
error: remote unpack failed: eof before pack header was fully read
error: failed to push some refs to 'git@github.com:yvoloshin-fidelus/Sugar.git'

This image shows a more detailed error message that I got from Github Desktop.

While following this SO post, I tried

git gc --aggressive --prune=now

and got this:

fatal: bad object refs/remotes/origin/HEAD
error: failed to run repack

Other git commands I tried with their outputs:

git count-objects -vH

warning: garbage found: .git/objects/pack/tmp_pack_2dy4gc
warning: garbage found: .git/objects/pack/tmp_pack_tnF02a
warning: garbage found: .git/objects/pack/tmp_pack_XY7JBa
count: 4904
size: 10.77 MiB
in-pack: 68200
packs: 4
size-pack: 1.15 GiB
prune-packable: 0
garbage: 3
size-garbage: 1.32 GiB

git gc --aggressive --no-prune

Enumerating objects: 65624, done.
error: failed to run repack25/65624)

These commands had no effect on the original error. What else should I try here?

yvoloshin
  • 378
  • 6
  • 18

2 Answers2

3

EDIT/UPDATE: What actually did the trick for OP was git update-git-for-windows. See comments for details!

Things I'd try in such situations:

  • Make sure my current user owns all the current git-internal files, as lacking permissions can interfere with various git operations.
    • Linux: sudo chown -R --changes "$USER" .git
    • Windows: open main folder permissions and let the permissions get rolled down via the Advanced Security Settings dialog (using ☑ Replace all child object permissions with inheritable permissions from this object)
  • On Windows: Make sure the path isn't long, as the Windows filesystem NTFS will mess up git if paths get longer than 255 chars/bytes. Keep in mind that the regular git object paths alone (e.g. .git/objects/fe/73f087d8c25fbc1159a50434ef9bf15773e7ac) have a length of 55 characters. Also that special unicode characters can consume more than 1 byte of the file path. Also files in the repo that exceed the maximum path lengths can become problematic for some operations. In worst case just move the repo to e.g. C:\repo\ or something in similar length and try there.
  • if even that fails and the repo seems completely broken, I'd try cleaning up the repo by cloning it locally git clone ./repo newrepo and retry the push from within the new repo clone
Jay
  • 3,640
  • 12
  • 17
  • Thank you Jay! I made sure that .git is owned by the "vagrant" user and ran the "Replace all child permissions" option in Windows. The problem was still there. Then I cloned the repo locally and got 7 "file too long" errors followed by "Clone succeeded, but checkout failed". This might explain the "remote unpack" error. The cloned repo is located inside the old repo (/oldrepo/cloned_repo). But now when I try to push from the clone repo, I get Permission denied (publickey). The ssh keys are located on the host in C:\Users\\.ssh. How can I make the cloned repo access the ssh keys? – yvoloshin Aug 01 '19 at 18:49
  • Are you using GIT-Bash to push? That one should load the key automatically, if I remember correctly. Although the message `Permission denied (publicly)` suggests that *some* key was loaded already. Are you sure you added the public key of that pair to your GitHub/account? – Jay Aug 02 '19 at 22:08
  • I was actually using Cmder and not Git Bash. When I tried to push the cloned repo using Git Bash, I got the same error with the cloned repo as with the original repo: "remote unpack failed: eof before pack header was fully read". – yvoloshin Aug 09 '19 at 15:44
  • Just in case the problem is the long file names, I followed [this post](https://stackoverflow.com/questions/22575662/filename-too-long-in-git-for-windows) and added `longpaths = true` to `C:/Program Files/Git/mingw64/etc/gitconfig`. This had no effect on the error. – yvoloshin Aug 09 '19 at 16:54
  • I also added the same line to `RepoFolder -> .git -> config` for both the original and the locally cloned repos, with no effect. – yvoloshin Aug 09 '19 at 17:04
  • 1
    After adding `longpaths = true` to `gitconfig`, I deleted the cloned repo and re-cloned the local repo to `/oldrepo/cloned_repo`. This time, there was no `Clone succeeded, but checkout failed` error. Both cloning and checkout were successful. I changed the remote origin from `/oldrepo` to the github repo using `set-url`. But another attempt to `git push` to origin resulted in the same `remote unpack failed` error. – yvoloshin Aug 09 '19 at 17:50
  • Sounds you're on a good way :) but it does increasingly sound like the remote repo is somehow broken :/ maybe try make a new repo **on the remote side** and see if you can push to there without error? – Jay Aug 09 '19 at 18:17
  • 1
    I think I solved this problem. Looks like all I had to do was to update git using `git update-git-for-windows`. It updated from 2.19 to 2.22. Now the `remote unpack failed` error is gone. But a new problem appeared. I now get `File database/sugar800ent.sql is 2627.60 MB; this exceeds GitHub's file size limit of 100.00 MB`. This makes no sense because this file does not exist and, as far as I can tell, never existed in this repo. But this is a different issue and I'll create a new post for it. Thank you! – yvoloshin Aug 09 '19 at 19:04
  • Great! Also that sounds like somebody accidentally committed the file into the repo and later removed it in another commit? It would still bloat the repo as it's contained in the history of git. It contents remain saved. Try `git log -- database/sugar800ent.sql` and check the size of .git (It's probably compressed though, so expect the size be less than a third of that file, but still large). See also: https://help.github.com/en/articles/removing-sensitive-data-from-a-repository – Jay Aug 09 '19 at 19:55
  • 1
    Yes, what you said is exactly what happened. git log showed two commits where this file was added and then removed. I had to run `git reset --hard` to remove the automatic local changes created by Sugar, and then I ran the BFG command. This removed the file from git history. After this, `git push` worked with no problems. Thank you again! – yvoloshin Aug 09 '19 at 21:22
  • 1
    You're welcome and thanks for the update. Have a great weekend! :) – Jay Aug 09 '19 at 21:28
  • 1
    `git update-git-for-windows` fixed it here too (Windows 11, updated to git 2.38.0.windows.1) – Jonas Lindeløv Oct 06 '22 at 10:52
0

There can be a few reasons this can be happening:

  1. You do not have enough permissions to push for the destination repo
  2. Your git head is corrupted- for this you can redo the git head setup again
  3. Or create a new branch and clone from the upstream repo and push the changes to the new branch- this worked for me since I did not have permissions on AWS.

I had an error as: "remote unpack failed- Unknown Commit 6879900878 error: failed to push some refs to "https:/git-codecommit.ap-south.amazonaws.com/[REPO PATH]"

Poornima T
  • 263
  • 1
  • 2
  • 8