What is the best way to set up a new $HOME/.config/darktable configuration and copy old picture library, styles and presets using darktable on Linux? The picture raw files all remain in their existing folders.
Background:
I trashed part of my $HOME/.config/darktable because of too much hacking, so I needed to start with a fresh .config. I recovered like this:
I renamed my old $HOME/.config/darktable to move it out of the way.
Restart darktable to get a clean $HOME/.config/darktable
Copy old library.db to (new) $HOME/.config/darktable
Copy old $HOME/.config/darktable/color/out to new $HOME/.config. (I use some non standard output color profiles).
Export styles and presets using darktable application pointing to my old config using ./darktable --configdir
Import styles and presets using darktable pointing to the new ./config/darktable
Q1: This worked from me. Is there a much simpler way ?
I guess this can happen again. I build from source and keep executing make install over and over again as new commit appear in dev repo. I think I reached a point where I needed a fresh $HOME/.config/darktable. I do not know exactly what happened. I had issues with color calibration color picker, but it works after starting with a fresh .config. I did not report a new issue since I did not have a clean case. Perhaps I just left an erroneous edit after inspecting a file in $HOME/.config/darktable.
Q2: Is it standard practice to start with clean $HOME/.config/darktable, from time to time, when you build from dev repo source and update build continuously?
library.db has your photos; data.db has your styles, presets and tags – you should also restore that, if possible. And shortcutsrc has your customised shortcuts.
In other words: an easy way to start fresh is to keep everything, just rename darktablerc to darktablerc.old.
For me it is not. I build from git master every few days but my $HOME/.config/darktable is “stable” since about two years. If I want to run tests with a completely clean install I use the commadline options --configdir and --cachedir pointing to empty directories.
I remember some problems with darktablerc (after a crash of the application) a long time ago, but was able to locate and correct the malicious entry. So no need to start from scratch.
Those files are backups of the database when you install a new version, so as @kofa said, they can be deleted.
It could be useful to keep the latest of them, until you are sure the current version works for you. changes in the program can make the current database (and/or sidecars) unreadable for older versions. Keeping the latest of the xxx.preyyy allows you to go back to that version and continue working.
Something similar goes for the snapshots, but since darktable only keeps a few of those, it’s not really useful to delete those (they’ll be recreated fast enough).
