gitmost

Files

T

agent_qa cec50c3ce4 fix(git-sync): a git edit that drops the gitmost_id frontmatter is no longer lost (C10-D1)

If a git-side edit rewrote a page file WITHOUT its `gitmost_id` frontmatter (e.g.
a tool that regenerates the whole file), the push planner's M (modify) branch found
no pageId in the current meta and SKIPPED the file — then the next Docmost->git push
overwrote it with the DB content, silently reverting the edit (data loss, found via
web-test).

Mirror the D (delete) branch: recover the identity from the PRE-IMAGE meta (the
last-pushed version at the same path, which still carried the id) before skipping,
and apply the body edit as an update. The pushed-back re-serialize restores the
frontmatter next cycle, so the file self-heals. Only when the pre-image ALSO lacks
an id (a never-tracked page) is it genuinely skipped.

Verified on the stand: editing a synced page's file with the frontmatter removed now
applies the edit (was reverted). Unit test: a modified file with no current pageId
recovers it from the pre-image -> update. git-sync suite green (705).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-03 05:41:42 +03:00

src

fix(git-sync): a git edit that drops the gitmost_id frontmatter is no longer lost (C10-D1)

2026-07-03 05:41:42 +03:00

test

fix(git-sync): a git edit that drops the gitmost_id frontmatter is no longer lost (C10-D1)

2026-07-03 05:41:42 +03:00

package.json

fix(git-sync): address PR #119 review #4 — symlink guard, dead-code cull, changelog + warnings/suggestions

2026-06-28 15:39:12 +03:00

tsconfig.json

refactor(git-sync): internalize the engine — first-class ESM, no vendoring bridge (#119 review)