That would (just like Git LFS) store full, separate copies of every single version of the large files I manage. I really, really don’t want to go there, nor do I have even a fraction of the hard drive space for that…

That’s what I meant when I wrote “Git submodules can only point to a whole different repository” - they can’t point to a path inside a repository, only to another repository root. That unfortunately renders them useless for me (I’d have to set up in the order of hundreds of small repositories for the sets of shared data I have).

I’m already using Git for source code related versioning, but some use cases involving large binary files with partial updates aren’t well covered by Git (I’ve gone into some detail in my reply to @vvv@programming.dev).

There’s also the lack of svn:externals in Git. Git submodules can only point to a whole different repository as far as I’m aware.

I’m already using Git, thus my experience with Gitea. I am well versed with svndumpfilter and git-svn to extract and migrate individual Subversion repositories to Git.

I’m not only hosting code, but I have several projects involving large binary files with binary changes. Git’s delta compression algorithm for binary files is so-so. Git LFS is just outsourcing the problem. Even cloning with --depth 1 --single-branch gives me abysmal performance compared to Subversion.

So I’m still looking for a nice WebUI to make my life with the Subversion repositories I have easier.

After finding out that tools that are to “bureaucratic” don’t stick with me (bureaucratic as in, I need to fill out forms to create projects/tasks, update them and follow defined workflows), I ended up with Trilium.

It at first looks like a very free-form note taking app (a tree of documents on the left, click and edit away), but it has a lot of extra functionality that lets you construct journals and tasks lists in the document tree (like its Task Manager which is already set up in the Demo notes of a new Trilium install).

I happened across the Kaiju No. 8 manga two years ago. While it’s not a never-seen-before concept, it kept me engaged until the last published issue (at the time). Definitely going to check that one out.

I’m on OpenRC, so I can’t say anything about systemd, but I have several SSHFS mounts (non-auto) listed in my fstab:

sshfs#root@192.168.0.123:/random-folder/ /mnt/random-folder fuse noauto,uid=1000,gid=100,allow_other 0 0

Is that similar to what you’ve tried in your fstab? I’d assume replacing noauto with auto should just work, but then again, I haven’t tried it (and rebooting my system right now would be very inconvenient, sorry).

It also might require you to either use password-based login and specify the password or store the SSH keys in the .ssh directory of the user doing the mount (should be root with auto set).