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.
Discussion
Loading...
Discussion
@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
@Eduardo Mercovich (él)
This is a lot of thanks for a modicum of effort, during which I improved my elisp — and it does very little to address the state of the world, alas!
Can I suggest you put your thesis under version control as soon as you can, if it's not already?
The day you realise your sweeping edits were the wrong idea it will save your hide, and it's often useful less dramatically on other occasions.
For a single document being worked on by a single person, you really need very little knowledge of git. Just three very simple things: how to set it up, how to store changes, and how to retrieve a previous version. You don't even really need to know how to retrieve to start with — you could happily leave this until later, even deferring this until you really need it. You could even in a pinch get someone else to do it. Whereas they can't help you if you don't have previous versions in a repository!
Setting things up
- navigate to the directory/folder your thesis is in, and
git init --initial-branch main
git add thesis.org'git init' sets up an empty repository. you don't need the --initial-branch argument but if you don't git will call it 'master' which some find offensive. As you may be making this public you may as well avoid this controversy.
(You do not need to worry about branching at all - I can't see why you'd want to branch your thesis. But there's always at least one branch and things like codeberg will display its name.)
'git add' is perhaps a little misleading. The repository is still empty at this point, you've just told git to track the file 'thesis.org' and store changes to it when you commit - which is the next step.
Storing changes
git commit -m "a message describing very briefly what changed"This stores all changes to the files git is tracking to the repository. After the first commit the repository will now have a copy of thesis.org in it, in the state it was when you committed it.
'-m' is for 'message' naturally.
"initial commit" is a traditional first commit message. Other examples might be "fixed references in chapter 3", "incorporated jamie's code" etc.
I recommend committing pretty frequently - maybe every day!
And that's all you need to know!
(I'm assuming you have git installed already. Let me know if you need help with that.
Also, I know you want to use magit but I've barely ever used it, and for these very simple use cases I think it's worth learning to use command line git. It means you can understand what others are talking about, and also cope if magit isn't available).
@Eduardo Mercovich (él) #tem25 #git #versioncontrol
bonfire.cafe
A space for Bonfire maintainers and contributors to communicate
Automatic federation enabled