Thread

1. jester997 · 1791061839 · focus · HN ↗

   The next platform for Agentic SCM is just… Fossil. Fossil is an SQLite database that can store anything an agent would ever need.

   1. mtzaldo · 1791062811 · focus · HN ↗

      I use beads + git; you just need to put the bead id at the beginning of the commit msg. The agents do the rest.

      1. jester997 · 1791066772 · focus · HN ↗

         What is beads?

         I am curious what people think about the use case that is different for AI agents compared to humans. Aside from the things people use SCM for already that is.

         Fossil fits the bill if you ask me because it has built in forum and stuff too, so Agentic discourse can happen there, commits happen in the SCM history. And it has auto sync so they can automatically sync their state.

         1. zhynn · 1791079699 · focus · HN ↗

            I looked into beads but I didn't see a way to make it work any better than fossil, and fossil does more stuff. My typical setup is to use the repo as a working directory, the tickets for todo, wiki/forum for conversation. There is also a chat interface, but I haven't tried that with agents yet.

            But I love fossil for this. You can create users for all of the agents (or agent roles). The CLI for fossil is just a binary and it compiles nearly everywhere.

            +1 over here for agentic fossil. With fossil the "work" is integrated in with the code. Beads separates this out, the beads are instances of work that agents can consume, and they aren't part of the work repo. I could see why you might want this, but I still think that fossil gives you more utility.

            More info on beads if you are curious: <a href="https:&#x2F;&#x2F;github.com&#x2F;gastownhall&#x2F;beads" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gastownhall&#x2F;beads

            1. ffsm8 · 1791098903 · focus · HN ↗

               i feel like dropping the review and test phase -- especially in the agentic context - is incredibly spicy though.

               So if I wanted to use fossil scm, i&#x27;d have to find a way to glue that on, and now ... we&#x27;Re basically in the same situation as with any other solution: it supports only a subset of the feature we want.

               and especially CI pre &quot;merge&quot; is a hard requirement, and fossil doesnt have any concept for that i think?

               But the last time i evaluated it was in the mid 2010s, so things may have progressed since? but couldn&#x27;t find anything on cursory glance and AI confirmed that position, but we all know how often its wrong... so how did yall solve that issue?

               1. mtzaldo · 1791154425 · focus · HN ↗

                  yes, I agree: architecthre design, linting, commit msg structure, unit testing and other ci gates helps to direct the agents into building better software.
               2. jester997 · 1791162431 · focus · HN ↗

                  Fossil doesn’t have GitHub PR capabilities per-se. But its design philosophy is different with a focus on smaller groups of devs and not so much drive-by patches. I think in the case being discussed for AI agents, it can be simplified.

                  If you want human review on the code I’m thinking keep it simple and just review in branches&#x2F;tags before merging OR even just have loose patch files.

                  As we’re seeing with resurgence of command-line utility by agents, that extends equally well to the O.G. diff&#x2F;patch. A PR is literally just a diff with commentary and an approval process prior to merging. Diffs can be attached to forum topics and so-forth.

                  Lots of possibilities, but I think the main thing discussed here is how is version control better suited to AI agents moving forward.

Unofficial Hacker News client; not affiliated with Y Combinator.