Add Obsidian community gitignore files

[chpatton013]

Reasons for making this change:

Obsidian is a highly-customizable application for markdown file editing/viewing. Obsidian "vaults" store your collection of markdown notes, all application configuration, and all installed plugin code under the .obsidian directory (although that directory path is configurable). A popular backup strategy for Obsidian vaults is to use Git; there's even a community plugin that will auto-commit and push periodically.

I developed my own gitignore files for excluding various internals of the .obsidian directory. I generate my gitconfig files by concatenating a bunch of URLs together, so I wanted to host these on my public fork of this repo. If they can be useful to other people, then I'd like to contribute them back to the community.

I am an enthusiastic new user of the application. I have no other affiliation with the project or its maintainers at this time.

Links to documentation supporting these rule changes:

Disclaimer: There's no simple reference I can provide here. I had to do some digging to put this together.

Obsidian's sample Gitignore file under their "Tips-and-Tricks" doc (link) contains a decent starting point. I tried to use this initially, but with the way they manage the plugins directory you either exclude everything about a plugin, or include everything (including its implementation). I wanted to exclude plugin implementation, but include plugin configuration.

To do that I would need to know how plugins were organized, so I installed a bunch of plugins and started investigating with find. I found that every plugin contained the same three files (main.js, styles.css, and manifest.json), and any plugins that I had customized settings for contained a fourth (data.json). All these file names were consistent within each plugin subdirectory, and no extra files existed within any plugin.

I sought out confirmation that this pattern was actually a rule I could rely on. I didn't find what I was looking for, but I did find a few resources that give me confidence:

• Obsidian's instructions about how to publish a plugin (link) surprisingly doesn't have a succinct explanation of which files may be present in a released plugin. With a thorough reading of the document you can find references to main.js, styles.css, and manifest.json.
• Obsidian's sample plugin repository (link) contains instructions that clearly (but again, not succinctly) indicate that main.js, styles.css, and manifest.json are the only three files contained in a plugin release.
• This Obsidian forum post (link) is the only reference I can find about the Obsidian plugin settings file (data.json) on the great wide web.

If this is a new template:

• Link to application or project’s homepage: https://obsidian.md/

---

I made three different decisions in these files that I should highlight for critique:

1. I included three different gitignore files for Obsidian, which a user would be expected to choose between. I haven't seen any other community templates here that do this, but I can imagine differing user preferences/requirements that fit each of these better or worse than the others:
   • NotesOnly.gitignore: Only include the files that make up the content of your vault. Ignore all Obsidian application-related everything.
   • NotesAndCoreConfiguration.gitignore: Include all your vault content and all the configurable settings for the core application. Ignore the workspace cache and everything related to community plugins.
   • NotesAndExtendedConfiguration.gitignore: Include all your vault content, the core application config, and the configurable settings for all plugins. Ignore the workspace cache and plugin code.
2. In each of my gitignore files, I ignored the workspace cache files that were ignored in Obsidian's sample gitignore. Someone might want to track these files if they put a lot of effort into their UI layout, but the right way to preserve that information is with the Workspaces core plugin (built-in plugin).
3. When deciding how to selectively exclude plugin code while including plugin configuration (see NotesAndExtendedConfiguration.gitignore), I went with the strategy of selective inclusion (exclude *, include data.json) rather than explicit exclusion (exclude main.js, styles.css, and mainfest.json). Since I haven't found any canonical resources documenting the full set of files that can be in a plugin's directory, I felt it was safer to err on the side of omitting unexpected files. You could argue that since we know a plugin release contains a known set of files, it's actually safer to err on the side of including all other files but those. Either works for me, and it's easy to change.

I hope this is useful for others. Let me know if anything here needs to change before it can get pulled into upstream. I'm happy to iterate with you on this.