Dear @jamie
Thanks a lot for your time and attention (and code, of course). 😉
I am about to go to a Conference in Helsinki and will be back on the 30th, so no hurry. I will try to move the thesis #tem25 in the in-between times but I'm afraid there won't be much of those in the next days. ;D
And, for sure, will try your code once I'm there and will report back. :)))
Again, thanks a lot. Your sharing helps us all to keep hope in people and work towards a better world in these dark times.
Best.
@Eduardo Mercovich (él)
One more humdrum piece of advice: backups!
A version control repository is not a replacement for backups. Repos need backing up too.
It achieves one function that backups help with, that's getting back to previous versions.
However, if it's on the same computer or drive, it does not help with hardware failure / loss of the computer / catastrophic operator error.
(It's also possible to ruin your repository if you're 'clever' enough. I've been this clever in the past. Not if you stick to absolutely simple things as per my recommendation, tho.)
The usual recommended minimum is the original plus two backup copies. Neither backup should be on the same hardware, and one should be in a different location (e.g. in the cloud, emailed regularly to a friend).
Backup regularly. Every day, or more frequently if you're doing a lot of work. How much lost work can you easily shrug off if your computer dies?
And the backups should be checked occasionally to make sure you really are backing up.
A remote repository (e.g. codeberg) counts as one backup, but only if your push changes to it regularly.
(Sorry if I'm telling you what you already know, with this and my last message about git. However, in the case of backups it's common for people to be terrible about it, even if they know better. For example, while I backup semi-regularly, the 'other location' is just a different room, which doesn't help if the house burns down. So some degree of exhoration/nagging seems appropriate...)
#tem25 #backups #versioncontrol
