Multi-User Collaboration

How Gitlas handles concurrent editors and why jj (Jujutsu) is worth considering.

The Problem

Gitlas is designed for multiple contributors — human editors (Obsidian, VS Code) and AI agents operating in parallel. Git handles the versioning well, but several pain points emerge:

ProblemWhy it matters
Merge conflictsTwo agents editing the same file block each other; conflict resolution during a push forces a synchronous stop
Branch overheadEvery short-lived change needs a branch name, a PR, and cleanup — friction for automated agents
No auto-saveIf an agent crashes mid-edit, uncommitted work is lost
Staging complexityGit’s index/staging area is an extra concept that agent tooling must get right
Rebase/merge frictionFiguring out whether to merge or rebase, and how to handle the result, adds cognitive load

A Complementary Tool: jj (Jujutsu)

jj is a Git-compatible VCS that works on top of a Git backend. It does not replace Git — it wraps it with a simplified, more robust user model.

Key Differences

AspectGitjj
Working copyDirty state, unversionedAuto-committed on every edit — never lose work
BranchingManual git checkout -b + namingAnonymous changes identified by persistent Change-ID
ConflictsBlocks push, must be resolved immediatelyFirst-class conflicts — can be committed and resolved later
Undoreflog + reset (destructive)jj undo works for almost everything
StagingIndex concept requiredNo staging — jj describe + jj new is enough
Git interopNativePush/pull to any Git remote; collaborators see a normal Git repo

Concrete Scenario: Two Agents in Parallel

Agent A (updates insurance.md)   Agent B (updates heat-pump.md)
  │                                │
  ├─ jj new                        ├─ jj new
  ├─ edit insurance.md             ├─ edit heat-pump.md
  ├─ jj describe -m "update rates" ├─ jj describe -m "log service"
  ├─ jj git push                   ├─ jj git push
  │                                │
  │      ✓ No conflict — different files
  │
  │     Both edit heat-pump.md at the same time
  │
  ├─ jj new                        ├─ jj new
  ├─ edit heat-pump.md             ├─ edit heat-pump.md
  ├─ jj describe                   ├─ jj describe
  ├─ jj git push ── CONFLICT ── jj git push
  │                                │
  ├─ jj rebase                     ├─ jj rebase
  │  (conflict committed)          │  (conflict committed)
  ├─ jj resolve                    ├─ jj resolve
  └─ jj git push                   └─ jj git push

jj never blocks on conflict. The conflicting state is recorded as a commit, and both agents can move on. Resolution can happen asynchronously.

Why It Fits Gitlas

  1. AI-friendly — No staging, no branch naming, no git stash. The MCP server’s operations (create_page, update_page, commit_changes) map directly to jj newjj describejj git push.

  2. Crash-safe — Every agent edit is auto-committed. A failed LLM call does not lose the working state.

  3. Git-compatible — jj stores data in .git/. Forgejo, Quartz, Obsidian, and CI/CD pipelines all see a normal Git repository. No migration needed on the server side.

  4. Incremental adoption — A single agent can use jj locally while human contributors stay on plain Git. The remote stays pure Git.

When Not to Use jj

  • Obsidian-only workflows: Obsidian’s Git plugin expects native Git.
  • Forgejo-native operations: PRs, code review, and CI still happen in Git — jj does not change that.
  • Single-user repos: The overhead is unnecessary if only one person ever writes.

Recommendation

Use plain Git for the canonical remote (Forgejo) and for human editors who prefer native Git tooling.

Give AI agents a local jj working copy. The agent’s MCP server operates against jj; the result is pushed to the same Git remote. This gives you crash safety and conflict tolerance at zero server-side cost.

AI Agent

  jj (local)

Git Remote (Forgejo)

Quartz / Obsidian / Humans

For a shared repository with multiple concurrent AI agents, jj removes the most common friction points without requiring any change to the rest of the Gitlas stack.