The git model, rebalanced

Coding agents changed our profession for sure. At the time of the writing, my daily workflow is organized around agents, tickets and worktrees. Projects are larger, I deal with more changes in flight. 20 pending worktrees at a time is nothing special these days. More like the low end, actually. In my current source tree, find reports that I have 70 dirs named dog/ and 83 named abc. These are libdog and libabc, in all the multitude of their combinatorial patching states. Yesterday, I reviewed and merged 10 jab commits, among many other things. The number of tickets that I can judge, accept and merge is over 20 a day currently; the rejected work I do not count, but I reject as much as I merge, or more.

What really helps here is very tight feedback loops. Overall, for the 4 months this codebase was in existence, it was 100% dogfooded. Beagle's development happened in Beagle as well. I typically run the code from the worktrees to browse or commit itself.

The code is not being built by some chain-of-thought process anymore. More like it coevolves with my understanding of the subject. I do not edit each tree manually anymore, I see a number of trees mutate towards the objective. I watch this evolution unfold, and I direct and correct it. It is not plan-then-code anymore, but more like direct-then-select.

Beagle is a git-compatible source code management system, but to navigate these new waters, I had to tune and rebalance the git model. This lists the key changes and I will defend each one:

To git or not to git? Accept git the data format, reject git the software. Run one shared object store (likely $HOME/.be/) and a ton of worktrees.
Monorepo or polyrepo? Both. A project gets structured into submodules and all the commands recur into submodules by default for seamless experience. Agents clone a subtree they actually work on.
Branch or rebase? Either. Neither. Beagle's approach is that each worktree is its own branch, we mainly do worktree to worktree fast-forward get/post (pull/push).
git employs URIs for remotes. Our local setup is complex enough that we need URIs to address local resources and states. Beagle effectively uses its own TUI browser to make things manageable; local URIs come in handy here.
Tooling? Issue tracking? Site generator? Beagle lets agents write their own tools in JavaScript. What can be done by a mouse click, should not be done by a GPU cluster.
C or Rust? JavaScript! Beagle the SCM is written in JavaScript while all the performance critical parts are isolated in relatively-stable C libraries wrapped by a minimalistic JavaScript runtime. Syntaxes, diff/patch, data stores and indices are all C pieces.

Each of the points is expanded in a separate post, with usage examples, see the links.