FIrst of all sorry for such a late reply from last 1 week I was travelling and I was not having access to email. ; ) > On 2 Aug 2025, at 2:33 AM, Skybuck Flying <skybuck2000@xxxxxxxxxxx> wrote: > > Thank you for your reply, it was fun reading ! > > My current plan to experiment with git, ai agents and parallelism is as follows: > > 1. Windows 11 as base operating system. why not linux distro(alpine or maybe ubuntu)? > 2. PostGreSQL database server (for windows 11) as back-end/support for: > 3. Gitea git server (for windows 11) for local git server/github-like support. Why not git itself? > 4. Git client (for windows 11) > 5. Gemini cli (for windows 11/npm/etc) > 6. Gemini 2.5 pro/cloud access from google. > 7. (Perhaps some) custom developed communication layer/channel utilizing PostGreSQL database server to store/retrieve messages for AI. (Still in testing phase). > > (Optional 8. I also considered MailEnable mail server (for windows 11), but I suspect using e-mail for AI-to-AI might be too slow because of e-mail anti-spam and throttling issues/rate limitters, and complexity overhead and processing overhead of e-mail protocols in general like smtp for sending, pop3/imap for receiving.) > > (Future maybe 9. Ollama/local AI models, but not powerful-enough hardware for now to run either large AI models or AI models with large context windows). > (Also tested 10. LM Studio to serve local AI models and mimic/fake OpenAI API for cli tools which use OpenAI API). > > I'd love to hear more from you, which software solutions you have tried so far, or what you are experimenting with it or considering for future use. > I experimented with using a local Git server setup and Docker pods (based on Ubuntu 22.04) on a GCP instance. The GCP host acts as the main Git server, and each Docker pod connects to it via SSH. This setup proved to be very fast. Each pod contains a clone of a common Git repository that includes an instruction file. Every pod has a unique hostname, and the instruction file includes commands specific to that hostname. A script reads the relevant instructions for each host, formats them, and sends them to the gemini-cli (for now). The CLI applies the changes, and then another script handles the Git workflow. I've experimented with multiple approaches for this step: 1. Direct commit and merge: After applying changes, the script commits them and tries to merge directly into the master branch. If any merge conflict occurs, it’s sent back to the CLI, which can choose to accept the new changes, reject them, or perform a manual merge. 2. Patch-based queue: Instead of direct merging, changes are converted into patch files and added to a queue (using a Docker-mounted volume on the host filesystem, which also solves the email issue). These patches are then applied in order using git am -3. This reduces conflicts but doesn't scale well. 3. File-level locking: A lock is used to prevent multiple agents from modifying the same file at the same time. For example, if one agent is working on file1, it's locked until that agent finishes. This approach significantly reduces merge conflicts. However, it's slow—while it works reasonably well for 2–4 agents, with 10–20 agents, the performance degrades to the level of a 2–4 agent setup but with many more conflicts. > Bye for now, > Skybuck Flying. > > > > >
