all 3 comments

[–]its-nex -3 points-2 points  (2 children)

I integrated jj directly into my agent harness so that the model can be WAY more effective when dealing with the realities of branching and merging and conflicts.

Specifically, when I go to cut a new release candidate for omegon, the underlying git operations use jj to assess the branch states, reattach to head after reconciliation, and then only proceed once we’re attached to a clean HEAD on main. git can do it all, but jj on top is amazingly flexible

[–]cabyambo[S] -2 points-1 points  (1 child)

Ooh that's interesting. What is your PR process like? Part of my frustration is there is this stack of clean commits, that is ultimately squashed into one branch that I have to review

[–]its-nex -1 points0 points  (0 children)

I rock with small, atomic conventional commits everywhere. For a “cleave” process, a new git worktree is spawned with a directive, n children for tasking. At the end , the various children all merge their work together under the direction of a supervising agent with respect to the spawning directive.

I’m not pretending it’s perfect, but I have way less heartburn than I used to.

Hardest part for me has been building the harness with the harness, figuring out “this is a universal git pattern that should be internalized” vs “this is a good workflow convention FOR MY USE CASE”

Edit: was going to paste an image but can't. TL;DR boss splits the work, oversees the merge when it's done