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.

  • Ordoviz@lemmy.ml
    0·
    2 days ago

    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 deadbeef

    Replace deadbeef with the commit that introduced that_one_big_file.

    For more complex history editing tasks, see git rebase in depth.

  • VibeSurgeon@piefed.socialEnglish
    0·
    2 days ago

    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 by git 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.

    • ComicalMayhem@lemmy.worldOP
      0·
      2 days ago

      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 rm method.

      • communism@lemmy.ml
        0·
        1 day ago

        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.

        • ComicalMayhem@lemmy.worldOP
          0·
          1 day ago

          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

          • communism@lemmy.ml
            0·
            1 day ago

            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.

      • VibeSurgeon@piefed.socialEnglish
        0·
        2 days ago

        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.

  • CannedYeet@lemmy.world
    0·
    2 days ago

    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 --soft

      • CannedYeet@lemmy.world
        0·
        2 days ago

        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.

    • ComicalMayhem@lemmy.worldOP
      0·
      2 days ago

      I’ve seen git reset before 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