[git] Can't push to GitHub because of large file which I already deleted

Currently I have

1. Empty GitHub repo
2. SSH server repo (main)
3. Local Repo

SSH server repo was the most up-to-date repo (production site) so I did a Git clone from there to local. I then tried to do a git push to GitHub.

Everything went OK but then it said something about filename.gz being too large for GitHub. I didn't need this file so I ran several Git commands to get rid of it from Git cache then pushed back to SSH server.

I don't see the large file locally but it's still on SSH server even though git diff returns nothing and git push returns "Everything is up-to-date" - And even though the file is not visible in local repo when I try to push to GitHub I still get error about it

remote: error: File fpss.tar.gz is 135.17 MB; this exceeds GitHub's file size limit of 100 MB

I followed steps under "fixing the problem" listed on GitHub help so shouldn't that have been enough?

How is the file still in the ether when it's not local or listed in git status/diff/push?

Make your local repo match the remote repo with:

git reset --hard origin/master

Then push again.

My unorthodox but simple solution from scratch:

• just forget about your recent problematic local git repository and git clone your repository into a fresh new directory.
• git remote add upstream <your github rep here>
• git pull upstream master
• at this point just copy your new files to commit, to your new local rep from the old one may be including your now reduced giant file(s).
• git add .
• git commit -m "your commit text here"
• git push origin master

voila! worked like a charm in my case.

git lfs migrate import --include="fpss.tar.gz"

this should re-write your local commits with the new lfs refs

https://github.com/git-lfs/git-lfs/blob/master/docs/man/git-lfs-migrate.1.ronn?utm_source=gitlfs_site&utm_medium=doc_man_migrate_link&utm_campaign=gitlfs#examples

Here's something I found super helpful if you've already been messing around with your repo before you asked for help. First type:

git status

After this, you should see something along the lines of

On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

The important part is the "2 commits"! From here, go ahead and type in:

git reset HEAD~<HOWEVER MANY COMMITS YOU WERE BEHIND>

So, for the example above, one would type:

git reset HEAD~2

After you typed that, your "git status" should say:

On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

From there, you can delete the large file (assuming you haven't already done so), and you should be able to re-commit everything without losing your work.
I know this isn't a super fancy reply, but I hope it helps!

I am adding to the first answer.

git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch ' HEAD

There will be some merge conflict from origin/master.

Your branch and 'origin/master' have diverged, and have 114 and 109 different commits each, respectively. (use "git pull" to merge the remote branch into yours)

Please run this

git reset --hard origin/master

It will throw away all my staged and unstaged changes, forget everything on my current local branch and make it exactly the same as origin/master.

Sometimes the file is kept in tracking history, try the following steps:

1. git commit, If you are seeing create mode with the big file listed, then do:

2. git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch filename' HEAD. You should see a bunch of Rewrites shown in your console which ends with:

   rm 'filename' and

   the last line Ref was rewritten.

It's done.

If the file was added with your most recent commit, and you have not pushed to the remote repository, you can delete the file and amend the commit, Taken from here:

git rm --cached giant_file
    # Stage "giant_file" for removal with "git rm"
    # Leave it on disk with "--cached". if you want to remove it from disk
    # then ignore the "--cached" parameter
git commit --amend -CHEAD
    # Commit the current tree without the giant file using "git commit"
    # Amend the previous commit with your change "--amend" 
    # (simply making a new commit won't work, as you need
    # to remove the file from the unpushed history as well)
    # Use the log/authorship/timestamp of the last commit (the one we are
    # amending) with "-CHEAD", equivalent to --reuse-message=HEAD
git push
    # Push our rewritten, smaller commit with "git push"

I had a similar issue and used the step above to remove the file. It worked perfectly.

I then got an error on a second file that I needed to remove: remote: error: File <path/filename> is 109.99 MB; this exceeds GitHub's file size limit of 100.00 MB

I tried the same step, got an error: "A previous backup already exists in <path/filename>"

From research on this website I used the command: git filter-branch --force --index-filter "git rm --cached --ignore-unmatch <path/filename>" --prune-empty --tag-name-filter cat -- --all

Worked great, and the large files were removed.

Unbelievably, the push still failed with another error: error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 fatal: The remote end hung up unexpectedly

This I fixed by directly modifying the .git config file - postBuffer = 999999999

After that the push went through!

I have tried all above methods but none of them work for me.

Then I came up with my own solution.

1. First of all, you need a clean, up-to-date local repo. Delete all the fucking large files.

2. Now create a new folder OUTSIDE of your repo folder and use "Git create repository here" to make it a new Git repository, let's call it new_local_repo. This is it! All above methods said you have to clean the history..., well, I'm sick of that, let's create a new repo which has no history at all!

3. Copy the files from your old, fucked up local repo to the new, beautiful repo. Note that the green logo on the folder icon will disappear, this is promising because this is a new repo!

4. Commit to the local branch and then push to remote new branch. Let's call it new_remote_branch. If you don't know how to push from a new local repo, Google it.

5. Congrats! You have pushed your clean, up-to-date code to GitHub. If you don't need the remote master branch anymore, you can make your new_remote_branch as new master branch. If you don't know how to do it, Google it.

6. Last step, it's time to delete the fucked up old local repo. In the future you only use the new_local_repo.

I got the same problem and none of the answers work for me. I solved by the following steps:

1. Find which commit(s) contains the large file

git log --all -- 'large_file`

The bottom commit is the oldest commit in the result list.

2. Find the one just before the oldest.

git log

Suppose you got:

commit 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

3. Git rebase

git rebase -i 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32

Tips:

1. List item
2. I just choose drop for the commits contains the large file.
3. You may meet conflicts during rebase fix them and use git rebase --continue to continue until you finish it.
4. If anything went wrong during rebase use git rebase --abort to cancel it.

So I encountered a particular situation: I cloned a repository from gitlab, which contained a file larger than 100 mb, but was removed at some point in the git history. Then later when I added a new github private repo and tried to push to the new repo, I got the infamous 'file too large' error. By this point, I no longer had access to the original gitlab repo. However, I was still able to push to the new private github repo using bfg-repo-cleaner on a LOCAL repository on my machine:

$ cd ~
$ curl https://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar > bfg.jar
$ cd my-project
$ git gc
$ cd ../
$ java -jar bfg.jar --strip-blobs-bigger-than 100M my-project
$ cd my-project
$ git reflog expire --expire=now --all && git gc --prune=now --aggressive
$ git remote -v # confirm origin is the remote you want to push to
$ git push origin master

rather than doing complicated stuff, copy your repo (on your computer) to another place. delete the large file. do a couple of push and pull. Then some of your files will be messed up having things like "<<<<<< HEAD". Just copy your backup into the old folder on the disk. Do another add, commit, push!

I found squashing more useful than filter-branch. I did the following:

1. Locally delete large files.
2. Commit the local deletes.
3. Soft reset back X number of commits (for me it was 3): git reset --soft HEAD~3.
4. Then recommit all the changes together (AKA squash) git commit -m "New message for the combined commit"
5. Push squashed commit.

Special case (from user @lituo): If above doesn't work, then you may have this case. Commit 1 included the large file and Commit 1's push failed due to large file error. Commit 2 removed the large file by git rm --cached [file_name] but Commit 2's push still failed. You can follow the same steps above but instead of using HEAD~3, use HEAD~2.

this worked for me. documentation from github Squashing Git Commits git reset origin/master

git checkout master && git pull;
git merge feature_branch;
git add . --all;
git commit -m "your commit message"

find documentation here

I had this issue when I didn't have a gitignore file with my iOS project

I think maybe it was trying to push a humungous file to github and github was probably rejecting that giant file or (files)

The solution to keep the large files/folders within the working folder

This is the line that worked to solve the problem asked here (from answer 1):

git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch <file/dir>' HEAD

This command also delete the file/dir if the file/dir is within the working tree.

If you want to keep the file/folder within the working tree I propose taking the following steps.

1. After that error run git reset HEAD^

2. Add the file/folder in question into ``.gitignore``` file.

3. Proceed as usual git add . which might capture other files/folders but must capture .gitignore file. Next is git commit -m"message" and finally git push origin <branch_name>

Why is GitHub rejecting my repo, even after I deleted the big file?

Git stores the full history of your project, so even if you 'delete' a file from your project, the Git repo still has a copy of the file in it's history, and if you try to push to another repository (like one hosted at GitHub) then Git requires the remote repo has the same history that your local repo does (ie the same big files in it's history).

How can I can I get GitHub to accept my repo?

You need to clean the Git history of your project locally, removing the unwanted big files from all of history, and then use only the 'cleaned' history going forward. The Git commit ids of the affected commits will change.

How do I clean big files out of my Git repo?

The best tool for cleaning unwanted big files out of Git history is the BFG Repo-Cleaner - it's a simpler, faster alternative to git-filter-branch specifically designed for removing unwanted files from Git history.

Carefully follow the usage instructions, the core part is just this:

$ java -jar bfg.jar --strip-blobs-bigger-than 100M my-repo.git

Any files over 100MB in size (that aren't in your latest commit) will be removed from your Git repository's history. You can then use git gc to clean away the dead data:

$ git gc --prune=now --aggressive

The BFG is typically at least 10-50x faster than running git-filter-branch, and generally a lot easier to use.

Full disclosure: I'm the author of the BFG Repo-Cleaner.