Merge with jrl #2
Description
I have recently started working with jujitsu and I have to say I'm amazed by my experience with the tool. There's already been features I pushed to make yac integrate with jj. I plan to document my experience on ulearn to add some littérature on the topic. -- I find it's sad that such a good tool is not available to all and that we're all stuck to hating git unless you prove to be a git wizard with all the magical attires.
On the side I also made a small proof of concept using jj as a repl, no more spamming the jj key but jj-ing instead. Of course it's very basic but I introduced a tokenizer that's at least is able to identify words separated either by spaces or double quotes blocks. Again nothing too fancy but as it is right now it fits amazingly well within my neovim sessions. There I start it with a terminal jrl command or if you would like throwing it like me with :term j<cr> with j being an alias to jlr. Of course these are just proposals and I'm sure you can find a -- much -- better way to set this up. But I now have a buffer rooted in my project home with jj waiting for instructions.
Now the issue is how to interact with yac with very little effort in the same repl. I would like to keep jrl independent from yac but at the same time inspire my self from the jrl experiment to build some TUI to couple yac with jj. As I plan to never come back to git CLI (RIP), I would focus on coworking with jj instead of git at the moment. But I will try to stay aligned with the previous features try not to break backward compatibility (e.g. with prompts).
The idea is to make yac interactive.
Currently the workflow I'm using is yac --no-post --debug-prompt as I found out gpt-oss 120b impresses me with the quality of the commit messages. The prompt should be reworked though. Support of more models and complex pipelines what I would like to aim right now after working on GoGroq. Indeed, Groq proves to be much faster the Claude and we don't really need it sonnet 4.5 to be an out commit redactor as "he" is more expansive both in token price and throughput time. I hope we can target for fast agentic work.
Another project I want to refer to is flattice go agent that would be a great foundation to build the future agents of yac to build complex custom pipelines.
Monitoring and offering the possibility to optimize costs should also be something to keep in mind.
This issue is a bit more than merging jrl into yac or yac into jrl. It's clear that they both rebase each others. But at least for the moment I want this to be a manifesto of this wonderful project that process to be really fun.
On my fork of jrl I will try to add special "dot commands" -- for which the first token is starting with . and the first candidate is .yac aliasing to yac --no-post --debug-prompt. The idea is that I can instantly edit the generated prompt (I can also .y --log @-,@,sh to give context about other commits to the generated prompt) and pipe it to some LLM to redact the commit (for example :w !GoGroq -stdout -stdin -key-env or just gG if you nmap it) after revision edits, generating more prompts and merging outputs, review the code etc. I'm ready to pipe it through :w !jj --describe -- or if you're lazy like me you can map it gJ. Anyways you have there powerful tools to make your "git" logs actually valuable. And it's "blazingly" easy. Not to say this code assistant helps you review your code when you see in the generated commit things you didn't intended to commit.
Now a couple of <C-o> escape sequences and you're back to jrl! There, don't hesitate and send a new command as you can edit your revision at any time! But you don't want to forget this step or you will be adding new changes to jj working copy you didn't intend to. Again I will try to make some content on jj to share a bit every thing I learned from the jj users and contributors to pollute a little more the internet on this cute related topics.
That's being said let's see where this goes :)