0

I am having big problems trying to push my code to my bitbucket server. My push is stuck on:

Enumerating objects: 536, done.
Counting objects: 100% (536/536), done.
Delta compression using up to 12 threads
Compressing objects: 100% (209/209), done.
Writing objects:  82% (242/295), 5.05 MiB | 236.00 KiB/s

The "Writing objects" has gotten over 2GB and then crashed with error:

I have tried git config --global http.postBuffer 524288000. I have read over a few articles and worked through guides: https://confluence.atlassian.com/stashkb/git-push-fails-fatal-the-remote-end-hung-up-unexpectedly-282988530.html

along with reading various StackOverflow questions to no avail.

I ran the command git diff --stat --cached origin/ and it returns the following: enter image description here

I have been working on this for days and really don't know what to do as I can't get my code pushed live to get to my staging server.

Bradley Kirkland
  • 621
  • 1
  • 6
  • 26

2 Answers2

2

enter image description here

Like described in the attlassian support your repository has a hard cap of 2GB and prevents you from pushing when your above this limit.

A repository is meant to store source code mainly, why is your repo that big?

ffm_nosoup
  • 97
  • 5
  • The code changes should not be as large as it seems which is why I'm confused about it, what do you suggest I do to check this? – Bradley Kirkland Jul 16 '21 at 00:08
  • Are there any other files than your source code files that may unintended have fiound their way into your repo? like a database file, or any kind of data in the same folder or one of the its folders as your source code? – ffm_nosoup Jul 16 '21 at 00:29
  • or one of its *subfolder – ffm_nosoup Jul 16 '21 at 00:37
  • I added a new image to show you, I found there was one but removed it. Still not working though, I've left it over an hour to run – Bradley Kirkland Jul 16 '21 at 03:06
1

You must have accidentally committed some huge file (e.g., a bootleg copy of The Fifth Element as a 4.7 GB DVD image) and then removed that file from subsequent commits.

Using git diff is no help here—at least, not without a lot of care. Imagine you had three phases in your life: when you were 12, you were 40 kg, then somehow you ballooned to 200 kg during your college years, after which you lost most of that and are back to a more sensible 75 kg. Now, compare a photo of yourself when you were 12, to a photo of yourself today. What do you see? git diff effectively works by picking two snapshots—two photos of your source files—and comparing just those two photos. It completely skips over all the intermediate snapshots.

Git, however, doesn't skip all the intermediate snapshots: each of those is a commit. If you have a commit with a big file in it, the commit remains in the history, which is nothing more or less than the set of commits in the repository, even if you have subsequently slimmed down all the new commits.

You need to find the commits that contain the large files, and discard them and all subsequent commits in favor of new and improved commits that lack the large files. See How to remove/delete a large file from commit history in Git repository? and related questions.

torek
  • 448,244
  • 59
  • 642
  • 775
  • I see, this actually makes sense! What I found when I did the git diff was that there was a big file in there. I then deleted it from the repo in hopes it would fix & rerun git dif where it wasn't showing, I also modified my .gitignore to help if it was some image I wasn't seeing. – Bradley Kirkland Jul 16 '21 at 05:50
  • I have tried running git filter-branch --force --index-filter \ 'git rm --cached --ignore-unmatch magento/magento/pub/media.zip' \ --prune-empty --tag-name-filter cat -- --all this seemed to have somewhat caused a rollback, however, it required me to pull and push the code. It created heaps of conflicts. I'm still having the same issue which is catching – Bradley Kirkland Jul 16 '21 at 08:11
  • Even after running the clear & running git diff I can't seem to see what the file is or how I can clear it, I'm hoping that I can push all the code and see if there are any code snippets which I can pull from all the commits to recreate a fully working version – Bradley Kirkland Jul 16 '21 at 08:14
  • The "however, it required me to pull" part is your mistake here. After filtering a repository you **have a new repository** that is not compatible with the old one. You must *discard all old clones* and use only *new* clones of the *new* repository. Using `git pull` means *run `git fetch`, then `git merge`*, i.e., you're telling Git that you'd like to combine all your new and improved commits with your original not-cleaned-up commits. – torek Jul 16 '21 at 08:15
  • In general, this may require using `git push --force`, since sites like GitHub don't really let you delete-and-then-re-create a repository. This is somewhat dangerous: it throws away the old commits in favor of the new ones. But that's what you want, **provided** the new ones are correct and the old ones are now old-and-lousy. :-) – torek Jul 16 '21 at 08:16
  • I haven't used Bitbucket and am not sure what their stance is on replacing an old repository wholesale (vs `git push --force`). The GitHub codes "dislike" this because it messes with their repository fork setup. (But so does `--force`, in some ways, so they might have changed things since the last time I looked into this.) – torek Jul 16 '21 at 08:18
  • Okay makes sense, I went through the whole codebase and manually removed all the <<>> and extra code but I seem to have overall broken the navbar, I'm hopeful I can get it to push and then I will be able to see what parts of the code are not correct. – Bradley Kirkland Jul 16 '21 at 08:19
  • It's actually caused the reverse effect that I wanted, it's overwritten my correct code with old code and now broken the project in course of doing so. Is there any way you can connect and help me fix this? If I can't get it back to work it will have cost months of work – Bradley Kirkland Jul 16 '21 at 08:48
  • OK: fortunately, Git tends to keep all your old commits, even after you've told it to throw them out in favor of the new-and-improved commits. Do you have a `refs/original/` name-space? (`git for-each-ref refs/original/` will print them.) Or: Do you have a backup of the original repository? (filter-branch encourages you to keep one; filter-repo requires that you start with one.) – torek Jul 16 '21 at 09:28
  • It also matters exactly what you did to *remove* the big file, which you haven't shown. There may be something useful in Git's *reflogs*. I'm going to be heading for bed though, and then offline for perhaps up to a week. – torek Jul 16 '21 at 09:39