0

I accidently commited a large file and now i'm stuck. I first tried this method: Fixing the "this is larger than GitHub's recommended maximum file size of 50.00 MB" error and received this message: "Cannot rewrite branches: You have unstaged changes." Since there was no indication if this was an error or informational message, i tried pushing again. Failed with the same error. and yes there are several similioar questions, but the solutions they present and i've tried do not work.

remote: warning: File Cyber Forensics/Work/Chapter 01/Ch01.zip is 96.05 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB

So then I went here: Stackoverflow but the first try failed in the same way

git filter-branch -f --tree-filter 'rm -f /path/to/file' HEAD --all

ditto with the second attempt

git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch path_to_the_file/your_big_file'

Now im concerned if i keep messing around I could really mess things up. Right now the only option I see is to clone the repository in a different folder and copy over everything except the huge files. But that is not the approach i wish to take, i would prefer to remove the large files from the commit.

user14202986
  • 153
  • 1
  • 1
  • 9
  • The message `Cannot rewrite branches: You have unstaged changes` means what it says: filter-branch is doing nothing because it believes there's something you must commit first. Someone else reported that filter-branch has lately been making this claim even though there *isn't* anything to commit; if that's the case, you and the other person seem to have run into the same bug. Otherwise, make the commit required, then use the index filter method (it's **much** faster than the tree filter method, roughly 100x faster, though both arrive at the same result). – torek Feb 18 '21 at 21:50
  • I already made the commit. the push fails – user14202986 Feb 18 '21 at 23:23
  • Yes, the push fails because one of the commits has the big file. Having a later commit that omits it (by deleting it when compared to the earlier commit) is insufficient. You must replace the old commits, with the big file in them, with new-and-improved commits that *omit* the big file (never have it in the first place). That's the point of filter-branch, but you can also use an interactive rebase to drop the big file, in many cases, and if you're in one of those cases, that tends to be a lot easier. – torek Feb 18 '21 at 23:42
  • it says no changes to commit and fails with the same files, same message, git filter-branch --index-filter 'git rm --cached --ignore-unmatch "Cyber Forensics/Work/Chapter 01/C1Prj03.E01"' merge-point..HEAD doesn't work – user14202986 Feb 19 '21 at 00:16
  • It says "no changes to commit" because you committed the removal of the file. You now have two commits: one that adds the file, followed by one that removes it. Git normally works by *adding new commits*. The added commits don't make the repository any *smaller*, no matter how many files you remove: those files are *already in the earlier commits*. You need to *remove **commits** not files*. – torek Feb 19 '21 at 00:20
  • If filter-branch isn't working (as I mentioned, someone else reported a similar bug), you'll need to find some other way to remove commits (I mentioned rebase above), or switch to some version of Git in which filter-branch does work. The bug, if you have it, sucks a lot, but I don't have a fix for it. – torek Feb 19 '21 at 00:21
  • so i issue the command git reset --hard HEAD~2 to remove the commits. but it fails on other files. Unlink of file 'C++/words.txt' failed. Should I try again? (y/n) n error: unable to unlink old 'C++/words.txt': Invalid argument – user14202986 Feb 19 '21 at 00:42
  • Well thanks for trying torek. I will just clone into a new folder. i thought it would be worth the effort to learn how to do this properly. but with bugs and all this uncertainty, it is not worth the effort just to kludge a fix. – user14202986 Feb 19 '21 at 00:50
  • Hm: `Unlink of file 'C++/words.txt' failed. Should I try again? (y/n)` indicates something has gone very wrong (e.g., some Windows process has that file open, preventing its removal). Probably what you did is best, at this point! – torek Feb 19 '21 at 04:25

1 Answers1

0

So I made things worse trying to fix it. I cloned my repository in a new folder and when i went to copy things over, there were a few files missing. I did a

git reflog

which produced: 2c87bfa (HEAD -> master) HEAD@{0}: commit: weekly 7128837 HEAD@{1}: commit: updating . . .

I couldn't undo what I did because I issued:

git reset --hard HEAD~2

But I had committed the files so I figured they had to be there somewhere. I wasn't able to push to the remote, so they were in the local somewhere. So I issued:

git log -g

which produced: commit 2c87bfa4507a2e960ed693810c42935829cb7745 (HEAD -> master) Reflog: HEAD@{0} Reflog message: commit: weekly

So I was able to get the files back by issuing:

git checkout 2c87bfa4507a2e960ed693810c42935829cb7745 -- "Structured programming/chapter5.cpp"

I had to do it for each file.

user14202986
  • 153
  • 1
  • 1
  • 9