I've recently set up a GitHub-hosted repository that manages an Obsidian vault folder, including the .obsidian config folder. Using the Obsidian Git plugin (and MGit on mobile), I can now sync my notes and plugins between my computer and phone. However, there is a problem: due to the way the mobile app handles plugins it doesn't support, two config files in the .obsidian folder—core-plugins.json and community-plugins.json, which list the active plugins—are changed automatically by the mobile app upon opening, marking any unsupported plugins as disabled (i.e. removing them from the list).
Ideally, I would like any changes I make to my desktop configuration (including to the config) to be reflected in the remote repository, since I would like to be able to seamlessly transfer the config to a new computer if necessary. However, I don't want the automatic "I can't use these plugins so I'll mark them as disabled" changes made on my mobile device to be pushed to the remote (or even committed at all). At the same time, I would still like to pull changes to those config files from the remote (so that any plugin additions on desktop are brought to mobile, whether they'll be supported or not).
From what I've seen so far, despite many such suggestions, the Git documentation strongly advises against using assume-unchanged and skip-worktree flags for this purpose. In addition, pulling changes from the remote would remove the assume-unchanged flag or fail with the skip-worktree flag. However, it's possible that smudge and clean filters might solve this problem, but I'm not sure how I would do that: I'm thinking that I could rename the relevant desktop config files on pull and push so that they are tracked separately to the 'shared' config.
Any suggestions (which might solve the problem) are welcome. To summarise, the situation is as follows:
- By default, local changes to the config files should be tracked (in some way) such that they can be automatically transferred to other machines
- The Android Obsidian app automatically changes some of the config files upon opening, and these specific local changes should not be tracked—or at least shouldn't overwrite the information required to reconstruct the 'full' plugin config lists