Let’s say I was doing stuff in a local directory. I added a large file, I commit and push, but I get an error stating that the file is too large. If I didn’t care about this file making its way to the Github repo, how can I go about removing it from the commit without ruining the rest of my progress? I tried deleting the file, re-adding and re-commiting, but I get the same error when I push. So far my workaround has been to copy everything in the directory except .git to a different, temporary folder, revert to origin/master, and then replace everything back in with the changes I want. I haven’t found a good solution for just… ignoring the large file or removing it from the commit, nothing I’ve found online has worked and the commit always just fails because of the large file.
Edit: hey everyone thanks for all the replies! I appreciate it, I’ll have to test out these sometime.
If it’s the last commit, you can undo the commit, and re-make it as you please by using
git reset HEAD~1. You can then stage the files you actually want in the commit.Another option is to amend the commit to not include that file, by doing
git rm --cached <filename>followed bygit commit --amend.The reason you can’t do the prior in a separate follow-up commit is that the file would still be in the git history, and hence it must be pushed to GitHub along with the rest of the repo files.
If the problem is not on the latest commit, you can do an interactive rebase, and re-do the commit that way.
The reason you can’t do the prior in a separate follow-up commit is that the file would still be in the git history, and hence it must be pushed to GitHub along with the rest of the repo files.
This makes sense. Is it possible to delete the offending commit completely? I use github like a cloud service for files, writing, and class notes, mostly just to push things from my laptop to my desktop and vice versa, so I’m not particularly worried about keeping commit history or anything. If not, then I’ll try out the
rmmethod.It is possible through several means.
The reset-method makes it disappear (and then you create a replacement).
If you have nothing you want to keep at all in the commit and it happens to not be the latest one, you can as mentioned use an interactive rebase. You then mark the commit for deletion, and it’s like it never even happened. If any subsequent commits depended on changes in the deleted commit, however, you will get conflicts, as git won’t know how to apply the subsequent commits in that case.
Is there a reason why you don’t use conventional cloud storage? The only reason I can think for someone to use a git forge for generic cloud storage is the version history, which you’ve said you don’t need. Something like your OP problem wouldn’t happen for a conventional cloud provider.
price, desire to keep out of commercial cloud providers + inability to host my own private cloud service, desire/need to be more familiar with git in general as a compsci major, and ease of use. those are pretty much the main reasons
desire to keep out of commercial cloud providers
I’m afraid that GitHub is run by Microsoft and I would consider it pretty thoroughly corporate these days.
Fair enough if you want to get more familiar with git (although using it as a cloud service is basically just gonna be add all and then commit, surely? you’re not practising any other git operations if only using as cloud storage?), but people normally do this with programming projects, which you should have no shortage of as a CS major.
I’m afraid that GitHub is run by Microsoft and I would consider it pretty thoroughly corporate these days
Ah. Did not know that. That’s… unfortunate.
although using it as a cloud service is basically just gonna be add all and then commit, surely? you’re not practising any other git operations if only using as cloud storage?
This is true enough actually but it helped drill the process into my head when I first started it and I found it simple enough to use after a while, esp since I just wrote a bash function to cut down on cd’ing.
but people normally do this with programming projects, which you should have no shortage of as a CS major.
You’d be surprised.
git reset --soft HEAD~1 ? This assumes it is not pushed to the remote already.
Yeah soft and then
--force-with-lease
If you have additional commits made after the commit that added the big file, you can use interactive rebase to edit the offending commit and redo the rest on top of it. If the offending commit is the latest one, then you can use
reset --softI’m not super familiar with rebasing or git in general, just the basics. What’s the interactive rebase?
That’s the sort of general question where I couldn’t give you a better answer than you could find by Googling if I tried. But for my own amusement, a one sentence answer is that it’s a sort of mega command that lets you do various types of rewriting history like removing, reordering, redoing, rewording.
I recommend using a good GUI for it. That’s usually a lot easier than vim or another text editor if you’re not ready to go down that rabbit hole.
git reset HEAD^ -- somepath/whateverfile git commit --amend --no-editI’ve seen
git resetbefore on stack overflow threads but I’m not sure how to wield it effectively. Last I tried it and followup commands, it didn’t work
Make sure your working tree is clean (if not, commit or stash your changes), then run
$ git rm ./that_one_big_file $ git history fixup deadbeefReplace
deadbeefwith the commit that introducedthat_one_big_file.For more complex history editing tasks, see git rebase in depth.
Someone else recommended
rmbefore but I hadn’t seengit history fixup deadbeefcommand before. I’ll test this out sometime, thanks for the suggestion and the link!Edit: I assume I used the commit hash for
git history fixup?
Use
git resetto repoint your branch head to an earlier commit, before the problematic oneI’ve forgotten most of my git commands I just tell an agent what I want and it happens.
Nice brainrot you got there (surely this is sarcasm?)
Wow thanks for the advice
