71–80 of 216 posts
Did you have your agent talk you into making this something separate over building on top of git?
Haha I wish, but I've been working on VCS's separate from git for a while now. Although I do love git, I've wondered for years before agents if something could be made using something different, rather than building something on top.
I have absolutely no idea what this offers that makes it better than git (or any over VCS for that matter) for agents. There’s some mention about performance, which is great, but the performance of git isn’t a bottleneck for agents. There’s some mention about token use being reduced, which is great, but how have they achieved that vs gits porcelain modes. And why does token count require a whole new VCS, and thus inc…
Eh, it depends on the workflow. Especially if you have certain stack based workflows. Worktrees are kinda half solution here but depending on the repo type and if you are dealing with LFS or sparse checkouts, I've had agents struggle really hard to work through a stack or rebase things without a lot of thrashing or being IO bound by just stumbling into operations in a boneheaded way. Now I have AGENTS.md/skills/hooks gaurdrails littered about to try and work around things.
Now, every brain fart is published as a finished product no one wanted.
Earlier quoted context omitted.
What is git not suited for in modern development? I haven't found any reasons.
Game development, with very large assets. Also, git is pretty terrible with non-text files.
Certainly an interesting project although I am wondering what makes the benefits mentioned agent specific? You have mentioned performance improvements which is great but in that case would it not just be a better vc than git in general? what perks only work with agents that wouldn't work with individuals?
Yeah, I'll just wait for jj to get more virtualized FS features, and be very, very happy with that.
Earlier quoted context omitted.
What is git not suited for in modern development? I haven't found any reasons.
1. Ease of use. Other VCS have more consistent command line interfaces; Git's interface has to be studied. In practice, people end up using GUIs with missing functionality and then end up searching for help, and a lot of real experts come to rely on powerful wrappers like Magit, LazyGit, or JJ. (Compare to Mercurial, Fossil or Git; those systems have consistent and usable interfaces. There's much less demand for wrap…
2. https://git-scm.com/docs/git-reflog
It’s very hard to loose data in git.
3. The goal of writing code is to have working software. Conflict messages are like compiler warnings, better have them than getting errors slipping by unnoticed. If A conflict with B, the root cause is often a design conflict, which means that the design of the software is inconsistent.
The conflict only matters as long as it’s not been solved. For each commit, the design of the software need to be consistent, and the succession of commit describe the evolution of the design. A is not lost, B is not lost in the case of a merge and may stay for a long time when rebasing. C which solves the difference between A and B (and may replace B) is also consistent. I don’t care about inconsistency.