140MB fresh repo size (without much code or data, not using LFS)

[WGierke]

Expected Behavior

After cloning using Git (and without LFS), after 30 commits and without test data, the repository should only be at most a few MB in size.

Current Behavior

It's over 140 MB when cloning the master.

Possible Solution

I guess that the reason is that in the beginning even big files were pushed using Git. When they were then transferred to Git LFS, they weren't removed from the "normal" Git history.

Steps to Reproduce

1. Clone the repository
2. Check its size (including hidden folders such as .git)

Context (Environment)

Detailed Description

Possible Implementation

Would it be possible to remove those big files from the history using references like Removing sensitive data from a repository or How to remove/delete a large file from commit history in Git repository?? Unfortunately, I'm not that familiar with LFS or history rewriting...

Checklist before submitting

• I have confirmed this using the officially supported Docker Compose setup using the local.py configuration and ensured that I built the containers again and they reflect the most recent version of the project at the HEAD commit on the master branch
• I have searched through the other currently open issues and am confident this is not a duplicate of an existing bug
• I provided a minimal code snippet or list of steps that reproduces the bug.
• I provided screenshots where appropriate
• I filled out all the relevant sections of this template

[reubano]

Tagging this as official (CR #17 and 7d46f08)

[pjbull]

@lamby I think we may need to rewrite history to reduce this size. Can you take the lead on:
(1) seeing if that would work
(2) making sure the history rewrite won't majorly mess up people's existing forks/PRs (?)

[isms]

Considering closing this issue - it's a data-intensive development environment in the best case so this doesn't seem to be blocking anything. Thoughts?