You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Enhance README and CLI with remote persistence features
- Updated README to clarify the purpose of `monodev` and introduced the concept of Local-First Overlays.
- Added new CLI commands for managing remote persistence: `push` and `pull`, allowing users to share stores across machines and teams.
- Implemented functionality to configure remote settings, including selecting a remote and setting the persistence branch.
- Enhanced commit logic to notify users of removed paths that are no longer tracked.
- Introduced a SnapshotManager for materializing and dematerializing stores between local and remote directories.
- Added tests for remote configuration management and snapshot functionality.
Copy file name to clipboardExpand all lines: README.md
+59-16Lines changed: 59 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,19 +1,13 @@
1
1
# monodev
2
2
3
-
I frequently work with a giant monorepo consisting of countless components nested at varying depths. Because of its scale, it has a noticeable memory footprint on my machine and imposes subotimal landscape for AI agents.
3
+
Most codebases suffer from "local file drift." We generate debug scripts, AI scratchpads (.cursorrules, .claude, etc.), and task notes that live alongside our code but don't belong in the repo. These files are either accidentally committed (clutter) or deleted too soon (lost knowledge).
4
4
5
-
To work around this, I selectively open individual components as isolated IDE workspaces, manually excluding irrelevant directories via settings.json. And during developing, I would additionally add various component-specific artifacts such as .cursor, Makefile, AGENTS.md, run.py, etc.
5
+
`monodev` introduces a third space: **Local-First Overlays**. It keeps your dev-only artifacts persistent and portable without ever leaking them into your Git history.
6
6
7
-
Long story short, these dev/component specific artifacts cannot easily be commited and persisted methodically, making their reusability difficult across different branches and sessions.
8
-
9
-
So I created `monodev`.
10
-
11
-
`monodev` is a local-only CLI for managing **reusable development overlays** (scripts, editor config, agent-instructions, Makefiles, etc.) across large monorepos.
12
-
13
-
It lets you:
14
-
- keep dev-only files out of git
15
-
- persist them safely per component or profile
16
-
- re-apply and remove them deterministically
7
+
The Monodev Way:
8
+
-**Invisible**: Keeps "git status" clean.
9
+
-**Persistent**: Your notes, scripts, and agent files survive branch switches.
10
+
-**Portable**: Push/Pull your local state via hidden orphan branches.
Share stores across machines and teams using Git-based remote persistence. Stores are pushed to a separate orphan branch (`monodev/persist` by default) to keep them isolated from your main repository history.
204
+
205
+
```bash
206
+
monodev init # initialize the .monodev directory in the repository root
207
+
208
+
# Configure which Git remote to use for persistence
209
+
monodev remote use origin
210
+
211
+
# Show current remote configuration
212
+
monodev remote show
213
+
214
+
# Set a custom persistence branch (optional)
215
+
monodev remote set-branch monodev/custom
216
+
217
+
# Push existing stores to remote
218
+
monodev push <store-id>...
219
+
220
+
# Pull stores from remote
221
+
monodev pull <store-id>...
222
+
223
+
# Pull and verify checksums
224
+
monodev pull <store-id>... --verify
225
+
226
+
# Force pull (overwrite local stores)
227
+
monodev pull <store-id>... --force
228
+
```
229
+
230
+
**How it works:**
231
+
232
+
1. Remote configuration is stored locally at `.monodev/remote.json`
233
+
2. Stores are materialized to `.monodev/persist/stores/` before pushing
234
+
3. A separate Git repository is created at `.monodev/.git` with an orphan branch
235
+
4. The orphan branch is pushed to your configured remote
236
+
5. When pulling, stores are fetched and dematerialized to `~/.monodev/stores/`
237
+
238
+
This approach keeps persistence separate from your main Git history while leveraging Git's compression and deduplication.
0 commit comments