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:
| Problem | Why it matters |
|---|---|
| Merge conflicts | Two agents editing the same file block each other; conflict resolution during a push forces a synchronous stop |
| Branch overhead | Every short-lived change needs a branch name, a PR, and cleanup — friction for automated agents |
| No auto-save | If an agent crashes mid-edit, uncommitted work is lost |
| Staging complexity | Git’s index/staging area is an extra concept that agent tooling must get right |
| Rebase/merge friction | Figuring 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
| Aspect | Git | jj |
|---|---|---|
| Working copy | Dirty state, unversioned | Auto-committed on every edit — never lose work |
| Branching | Manual git checkout -b + naming | Anonymous changes identified by persistent Change-ID |
| Conflicts | Blocks push, must be resolved immediately | First-class conflicts — can be committed and resolved later |
| Undo | reflog + reset (destructive) | jj undo works for almost everything |
| Staging | Index concept required | No staging — jj describe + jj new is enough |
| Git interop | Native | Push/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
-
AI-friendly — No staging, no branch naming, no
git stash. The MCP server’s operations (create_page,update_page,commit_changes) map directly tojj new→jj describe→jj git push. -
Crash-safe — Every agent edit is auto-committed. A failed LLM call does not lose the working state.
-
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. -
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 / HumansFor 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.