Git Transport for Coding Agents
Your Git remotes don't need to be remote. Adding a local remote, another Git repository on your filesystem, is perfectly acceptable to Git. I've found this pattern to be helpful for coordinating edits across repositories, all locally. I'll assume you have a bunch of repositories you've been working somewhere under your user (home) directory. The trick works like so.
git
├── ents
│ ├── git-data
│ ├── git-rewrite
│ ├── git-template
│ └── git-vendor
└── mirdain
├── flux
├── forge
├── hearth
└── kilnAssume I'm working on git-data, and I'd like a tool's configuration file to have edits that are similar to previous edits in git-rewrite.
Let's pretend the differences between file content are large enough that a simple copy won't suffice.
I could tell an agent look up the git-data repository on GitHub and read the configuration file; I want those same settings applied here, but then the agent would need to fetch the full file into context.
Agents are capable of making API calls to get information.
Instead, I've found myself doing the following.
git remote add git-rewrite ../git-rewriteWith the new git-rewrite remote, I can tell an agent I like the git-rewrite remote has configured this tool; I want those same settings applied here.
Agents are great at Git plumbing commands.
This has produced far fewer round trips, and while I haven't collected any data, I feel like context sizes have remained smaller because searchers can be more targeted.