You may have problems saving changes when your disk is full. Try removing unneeded files, and running git prune; git gc from the Console
Run those commands. If they don’t work, contact support@glitch.com for more disk space for 24 hours.
Hey Mr. Rocks 
Can you confirm what I’ve read online about git prune and git gc? I tried it recently but not much happens.
So first it appears that one runs git gc only and that git prune runs automatically from there. Maybe I have that wrong but more than one website reported that. And I think it would be helpful to know what it does.
It doesn’t “magically make disk space appear”. It removes some git history doesn’t it? So not you necessarily but someone might endeavor to give us a clue as to how much disk space that could reasonably be. If it is 2K that isn’t likely to be the major source of the problem.
Would 100 GIT check-in and merges add 100K? 10MB?
I received the message as well and would be very curious to know if anyone has ever run those two commands and then sat back as their disk space issues disappeared.
1 Like
Yes, that’s very true. These commands are a bit of a bandaid fix. I’d rather Glitch suggest to remove big folders and files by hand instead.
But with that being said, 100kb is quite a bit when coding. That’s about 50 pages in a word document!
1 Like
I once checked out the official Git docs in regards to git gc. It does seem to actually help with disk space by clearing out old and extraneous files. But a “heavy” project is probably…a heavy project. 
I assume that there is value or the command wouldn’t exist. The keys considerations (I think) are how much. I saw that git doc page and I found a few others that mention it and prune and the --aggressive flag and other things.
From that site:
Prune is considered a garbage collection command and is a child command of the git gc command.
This person outlines other commands:
And this guy (more or less) recommended against --aggressive
https://chris.tonkinson.com/posts/2016-10-10-how-to-recover-20gb-of-disk-space-back-from-git/
And I have to assume something is “lost” in the process. If it is purging history and old references does it means that we no longer see the check-ins in history? If so this could matter in projects where such tracking is a form of documentation.
And I have no idea about when to do it. If my git repo has all the detail and I pull it into Glitch I would have the unwanted files. Hopefully this isn’t enough to put us over the limit before we started. When I run git -gc (and or other commands) the copy on Glitch has been made smaller but not the one on the git repo.
So should the gc be called on each pull? Can the cleaned repo be pushed back or (as I would guess) would that only make the logs that much larger?
If it works well I would love to hear a “before and after” story. Perhaps someone could check their disk space now and then run the utility and report it after. I don’t doubt for a moment that it wouldn’t work I’m not sure it is worth the effort (unless it is very easy) in order to save 20K.
I have a discord bot that currently reports 3 MB / 400 MB and an AltSpace MRE that reports 92 MB / 400 MB. The bot isn’t close to a problem and even the MRE isn’t if it turns out that it was “shrunk” by 1 or 2 MB. If it reduced it by 10% by running a simple command I’d probably do it.
Which brings me to another question. Do people create shell scripts with this type of functionality? I’m not fluent with Linux and constantly refer to notes.
I personally never pull repos back and forth from Github to Glitch because I’ve lost files in the process. I don’t think it was ever with one push, but after it happened a few times, I just don’t bother with it. It can be annoying enough waiting for the editor to fire up, and I’m just not that diligent sometimes. If I’m in a bit of a hurry, I’ll just forget a step and make a mess. I definitely use Github for anything Node that isn’t something I’m just storing for reference. But React/Vite is easy (fast) on here now.
I think there probably isn’t one catch-all solution because someone might get unwanted results (like if it does clear some history but they wanted to keep it) but then someone else might not care about that.
At the end of the day, I don’t think this platform is quite meant for the most ambitious of projects (yet). So these commands probably work for most, and anyone using Glitch just really wants to use it, so …they keep using it, until they can’t. Github is still free. It’s not my favorite, especially after the Microsoft purchase…but there’s also Bitbucket. I use all 3! Oh, and Codepen. 
Interesting as I push from my PC to GitHub all the time and pull from GitHub into Glitch for every release. I just about never edit on Glitch but could make a patch if something needed immediate attention. I would then edit on my PC, push to GitHub and pull the update so there is a record of everything.
It not only works well for me it is how I was able to overcome my disk space issue so easily. I needed to pull the code and set a few .env variables. It would be more difficult if there was a database file. They download when one downloads a project so it isn’t too hard but if it contained production-grade data it would have to be done considerably more often or perhaps a script could run to pull changed data.
I will (at some point) run the command that reports what would be recovered if I ran git gc. I’m interested but not enough to drop everything to find out As for it not being a catch-all that is definitely true but each message that mentions it treats it like a catch-all. People are just told to run it. Might help a lot might maybe not at all. Might remove important tracking, might need to be done daily, that is never mentioned.
I mean, it’s probably to the company’s advantage if people are paying to boost their apps 
But not so much if they end up with a ton of support tickets.
I don’t think I saw anything about git gc clearing logs, and it probably wouldn’t need to be done daily, assuming it only clears files on your own repository or container. From the official git docs - “Running git gc manually should only be needed when adding objects to a repository without regularly running such porcelain commands, to do a one-off repository optimization, or e.g. to clean up a suboptimal mass-import.” There are various flags for different use cases beyond that. I think the --prune=now is a good one to know because the default time is 2 weeks. That should clear out extraneous files up until the present.
In hindsight I think I had issues when I pushed files from Glitch to Github and back, but I also thought I could keep one and not the other. It was a while ago. It sounds like pushing to Github first might be more reliable. I might try that if the need arises.
Hi all! We actually just deployed a change that updates the status tray for projects hitting their disk limit to show a link to this help center doc instead of just instructions to run git gc/prune. Historically, it was large git histories that caused disk space limits, but we’ve grown enough to see more varied reasons for those limits being hit.
1 Like
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.