Removing IL2CPP_cache from Project

I’ve been trying to push my project to an online git repository, but a particularly large program debug database file which I’ve traced to the il2cpp_cache folder in the project’s Library folder is preventing the push from going through.
I’ve switched to the Mono scripting backend, and I’m wondering if anyone can tell me if it’s safe to remove the il2cpp folders without breaking anything?
6990161--825437--upload_2021-3-30_16-26-10.png

You should not source control ANYTHING in the Library directory.

https://docs.unity3d.com/Manual/ExternalVersionControlSystemSupport.html

3 Likes

There’s only a few things outside the Assets folder you want under version control, and the Library folder is not one of them.

1 Like

Thanks, wish I’d known about this at the outset. Does the .gitignore need anything done to it bar dropping into the root folder of the project. I also notice there’s a few differences between the format it comes in, and what an auto-generated .gitignore produces:

I assume there’s no modifications that need to be done here? Also, do ignores work retroactively on previous commits, or is there more work to be done there?

Not sure what you are “auto generating” with… I usually start from one of my other projects, or a gitignore example online, and reason about all the parts inside it, and start from there. Like any other configuration change, after you make it, pay attention for a while to make sure it is what you want.

You can always clone the repo somewhere else to verify that the correct files are being tracked. Doing so to a brand-new computer is the acid test to make sure you can still build the project.

Not sure what that means… the .gitignore file is a file like any other file, a file that may need updating through the life of your project, such as whenever you … wait for it … need to ignore different sets of files! :slight_smile:

No… think of previous commits as having been etched in stone. Changes to previously-tracked files will also continue to need committing forever, until you git rm those files AND have the .gitignore set to ignore them. Only at that point will they go away from the auto-proposed commit sets.

In other words, the huge file blocking you from uploading to a free provider will remain there and will remain blocking you. You can strip old commits and files from git but it’s a long tedious annoying process. There’s google help but it’s still a lot of fiddling.

My personal recommendation would be to abandon this repository and keep it around for historical reference, then make a fresh empty repository (WITH a correctly-configured .gitignore!!) and commit all your work files from the original repo at once, and move forward from there.

1 Like

Given I don’t have much in the line of commits or pushes yet, I’d agree that starting afresh is the way to go. Thanks for going through the importance of all this, other than setting up a repo, very little of this was explained in college and I’ve gotten by on the basis that nothing has not worked until now (can’t fix the problems you don’t know you have). Going forward I’ll be a lot more stringent with my version control.

I’m managing my repositories through Sourcetree, so what I mean by auto-generate is that it can flag files for ignoring and create/update a .gitignore. When I say modifications, I mean that /[Ll]ibrary/ will ignore the Library (or library) folder without needing to add in the project folder, for instance.

Yeah, given my experiences of the last few days, I figured that might have been. I managed to remove the large file using BFG last night, but given the amount of cleanup needed to get rid of, a new repo is the way to go.

Thanks for you help guys.

2 Likes