I still look at the files I want to change so that it doesn't go off and grep the entire project unnecessarily, burning tokens or getting the wrong idea.
So I still use a ton of fzf.lua to find the files to change and I have just added some keybinds to copy the open file path to the clipboard so that I can paste the path of the file to change it into opencode.
Code diffs I definitely look at locally with delta via lazygit or jjui. codediff.nvim is also good for resolving conflicts.
The main thing I've changed is just using JJ so merge conflicts can be resolved later by me manually without it blocking bringing in new changes.
If I just hand over the thinking entirely and don't know what has changed until I'm looking at it in GitHub I feel that removes the need for me entirely as by that point I'll be biased and will be less likely to change things to how I'd like them to be.
That's fair enough! I think the flow will be more universally beneficial if things like this become more mainstream. https://github.github.com/gh-stack/ because then big prs aren't necessary if they can be reviewed incrementally so long as they can stand on their own.
I would imagine why the types were chosen could easily be explained in the commit message. The goal presumably (at least how I do it) is so that if I'm touching quite a lot of the code base, the reviewer has the _option_ of being taken through the narrative of the change like they might explain if they were talking to you. If you don't want to be told what the changes are and how they tie together, then just click on review changes and review it all at once. It's not about the clean history, it's about making the reviewer's life easier with larger features.
The commits might get squashed anyways so the history on main won't necessarily match what's on the feature branch.
You can commit before you raise a pull request, I don't quite understand that point but I might just be missing something about your workflow that's different to mine.
I've used it in the past and personally loved it. Just bumping a yaml file in a git repo to the image tag I wanted deploying was a godsend and nearly automated. I can't speak to your experience though which I am certain is valid and a real problem. We just never had those kind of issues so we could either revert to an earlier tag that worked or publish a new image with the required resolution steps.
https://fluxcd.io/ + helm + with a CI pipeline that pushes the docker images to a registry means that after the setup, anytime you push a new image and tag, k8s can automatically update without needing to do anything manual.
I tried tig first, I think Lazygit is the ideal interface to me for it. I actually don't use it apart from tags now though as I switched to jj and jjui for 2026. I think everyone has their own tool that works for them so it's hard to go wrong with a lot of these tools
https://github.com/duckdb/duckdb (performant database that lets you directly query JSON, parquet, csv files with SQL queries and convert one to the other.
https://github.com/eradman/entr (rerun commands automatically when provided files change) (useful for rerunning test commands automatically once you save the file you're editing.
https://github.com/jdx/mise (fast asdf, direnv, and task runner replacement) (install pretty much version of tool, language, env vars in a per directory level. (Or global if you want))
You may like https://httpie.io/ if you've not memorised all the curl flags already. The CLI tools way of making requests with headers and post bodies is really nice in my opinion
Yes tab split, neovim on the left, companion on the right, or different tabs. The plugin codecompanion.nvim is also great. I use it for common tasks. Like:
vaf (visual around function)
<space>ad (leader key add docstring).
And it documents the functions with my system prompt instructions for what good docstings should look like.
I sometimes get balls for cheap on sites like https://www.lakeballs.com/ (basically the rich people hit the prov1's in the lake and I get them on discount.)
So I still use a ton of fzf.lua to find the files to change and I have just added some keybinds to copy the open file path to the clipboard so that I can paste the path of the file to change it into opencode.
Code diffs I definitely look at locally with delta via lazygit or jjui. codediff.nvim is also good for resolving conflicts.
The main thing I've changed is just using JJ so merge conflicts can be resolved later by me manually without it blocking bringing in new changes.
If I just hand over the thinking entirely and don't know what has changed until I'm looking at it in GitHub I feel that removes the need for me entirely as by that point I'll be biased and will be less likely to change things to how I'd like them to be.