Large files management

[milivojm]

Considering deletes and updates of files are frequent and git as source control doesn't play nice with large files and keeps all changes in history forever, let's try and think of ways of

• keeping the build process simple,
• development process simple,
• keeping the storage levels down as much as possible

[freghar]

One reasonably easy way (that doesn't involve git lfs or google drive) is to version only the configs and throw away the history for the big binary blobs, using one branch for configs, and an orphan (no common ancestor) branch for the blobs. The config branch would be versioned as usual, the blob branch would just contain one commit that would always get git commit --amend-ed and force-pushed, so that no history is ever created.

The old big blob commits would remain in a local reflog, but they'd be garbage-collected after ~90 days as any dangling objects.

The deployment could be automated as git clone by default always clones all branches, so it would be just a question of

git fetch --all  # just in case
git checkout origin/big-blob-branch -- .
<pbo packing logic here>

(this would leave garbage in the local repo, but a cleaner solution of course exists with a temporary directory as external worktree, the above is just simple demo)

[milivojm]

People still use github desktop client, it will be a nightmare for them. :/

But certainly, an option.

[freghar]

How about just putting the asset directories onto google drive and pointing the README to it, saying to download all the folders into addons before packing all?

It would be a pretty manual process, but probably acceptable given how infrequently the assets change ... not to mention super fool-proof.