Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trim down repo size by excising old assets #140

Open
ResidentMario opened this issue Jul 5, 2019 · 3 comments
Open

Trim down repo size by excising old assets #140

ResidentMario opened this issue Jul 5, 2019 · 3 comments
Labels

Comments

@ResidentMario
Copy link
Owner

ResidentMario commented Jul 5, 2019

The geoplot documentation is currently built in several independent steps. One of these steps is generating the Plot References section, which is done by running the generate-api-reference.ipynb Jupyter notebook, which writes image files to a plot-specific directory in the docs/figures folder. These (binary PNG) files are checked into the repository as-is.

The same is true of the notebooks in the User Guide as well as the Quickstart notebook.

When an update is made to the library that has a cosmetic effect on the plots, to keep the documentation up-to-date it becomes necessary to re-run these notebooks, regenerate these images, and recheck them into the repository.

The problem this causes is that when there are many incremental changes to the image in the documentation, the size of the repo upon cloning quickly swamps. This had already been an issue in the past (see #37), and it's even more acute now as I come to the end of a long feature sprint.

To bring the size of the repo upon cloning back down to a manageable level, it is now necessary to run the BFG Repo-Cleaner again on the offending files.

See also #141.

@QuLogic
Copy link
Contributor

QuLogic commented Sep 13, 2021

This would be fixed by #253 + #254.

@ResidentMario
Copy link
Owner Author

#253 and #254 are going to prevent this from becoming a problem in the future, but they don't help the fact that the repo is over 100 MB right now, so I'm going to this issue open for now (until I can do another pass with BFG).

@QuLogic
Copy link
Contributor

QuLogic commented Sep 13, 2021

Sure, if you wish; that does change all commit hashes (after the first extra file gets deleted), which breaks tags and forks. You will have to be careful to not re-introduce the files from pre-existing forks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants