Idea for perhaps better system for default settings #40
Description
I have been making a few issues, and I thought I'd try my hand at implementing the ideas myself (learning a bit of obsidian plugin stuff along the way...). The first thing I thought I'd try was to "simply" make the toggle for whether to track Pull Requests a part of the global defaults, so I don't have to go through and turn this on for each of my repositories (call me lazy...).
I quickly realized however that this is not possible. Currently the logic is to prefer the global default OVER the repository setting for all settings except for the Folder/Template settings, so long as ignoreGlobalSettings is False. If the latter is True, then all global settings are ignored completely. This was counterintuitive to me -- I expect that my per-repo settings should override the global defaults. However, I see the reasoning: if per-repo settings override global defaults, then when I add a new repo, its settings must match the defaults to begin with, otherwise they automatically change the defaults. That in itself would be OK, but then there's the question of what happens when I go and update the defaults -- do all the current repos update their settings? How do we know whether the user wants every repo to change?
So, I see why it has to be the way it is. But still this is counterintuitive, and leads to situations like having to toggle all repos to switch on PR tracking (and not including that as a global default, because then you'd get inconsistencies).
My first thought was to change all the repo-level interfaces to accept an extra option: 'default', which would then get evaluated to whatever the global default is. This would be ugly though: booleans would need to become lists/dropdowns for example, and there'd need to be more complicated dynamic evaluation in the settings-tab.ts and repository-renderer.ts modules.
Perhaps a better way, however, would be to simply have a list of sets of settings independent from the list of repos. Each repo only has one setting: which set of settings it corresponds to. This is a way to have multiple "defaults".
To make the UI easier, you could provide a "clone" button next to each set of settings to make a new set based on a previous set. So, the user could end up with say three sets of settings: for example:
- A full default set of settings that we provide
- One that they clone and set "track PRs" to True
- One that they clone from (2) but set a custom template Path
Then, each repo just needs to point to one of these "sets". Here there is no complicated logic about inheritance of settings. The only "inheritance" happens at ONE TIME when the user creates a new set of settings derived from an old set.
I guess you could argue that if a user ends up with essentially one set of settings per repo, then the process of updating a single setting for all their repos is still arduous (they have to udpate it individually in each set, rather than in one place), but I think it's much less likely for this to be the case. I would expect most users to need only a couple of different sets of settings that would cover all their repos.
I hope that makes sense... what do you think?