Ask anyone who reviews pull requests against a shared docs repo what wears them down, and the answer is rarely the writing. It is the noise: the forty-line diff for a typo, the review where you scroll past hundreds of lines of formatting to find the one sentence that matters, and then approve it anyway because nobody has time to argue with an editor.

Consider an ordinary Tuesday in a vault that one product team, two technical writers and a researcher share in GitHub. Maya, a product manager, opens the roadmap note in specgit to change one date. Her note is crowded with [/] and [-] tasks, a folded warning callout and Dataview fields, yet the date is the only thing she needs, so she changes it and saves. When her tech lead opens the review, there is exactly one changed line to look at, and no reason to wonder whether the callout or the task statuses survived.

Sam, a technical writer, works in Obsidian on his laptop with the Tasks and Linter plugins, so his saves arrive with tidied list markers and freshly stamped done dates. He pushes while Maya still has the note open. specgit folds his changes into her open note block by block, her edits stay put, and nobody sees a dialog, because nothing conflicted. For the reviewer, the quieter win is that specgit doesn't put back the list markers Linter changed, so the vault never slides into a slow tug of war in which every other commit undoes the formatting of the one before it. Only when two people change the same paragraph does anyone get asked, and then only about that paragraph.

The afternoon is where shared vaults usually go wrong. Maya opens the team's launch board, an Obsidian Canvas file, moves one card, edits a word on a second and bumps a footnote on a third, a small session that lands in three files. Through a generic editor that session becomes 3 files changed, 285 insertions and 49 deletions, with 301 of those lines spent on the one card that moved, and any teammate with their own change to the board inherits a merge conflict. In specgit it comes to 3 insertions and 3 deletions, one line per file, each exactly the line Maya meant to change.

One-line diffs are a form of respect for the person reading them. They keep the vault's history honest about who changed what, and they let the people who'd rather work in Obsidian and the people who'd rather work in a browser edit the same vault without fighting over it.

This is what Obsidian for teams can feel like when the vault lives in GitHub, and specgit is built for Obsidian vaults that live there. The full post walks through both Canvas diffs line by line and shows how specgit is tested, including against the Obsidian app itself: specgit.com/blog/obsidian-fidelity.