Comment by tcoff91
13 hours ago
I was a big fan of a good keyboard-driven git TUI like magit, neogit, lazygit, etc... (as long as you learn the CLI first and understand it).
Now I no longer directly use git, but instead use jujutsu (jj).
Once I became very proficient in the jj cli, I picked up jjui: https://github.com/idursun/jjui
Also, as splitting commits is an extremely frequent operation, this neovim plugin is really nice: https://github.com/julienvincent/hunk.nvim
Also this neovim plugin is amazing for resolving jj conflicts: https://github.com/rafikdraoui/jj-diffconflicts
Now with jj instead of git I edit the commit graph as effortlessly as if I am moving lines of code around a file in my editor.
Thank you for the many tool links! You seems to know this space well. I have come to pick your brain for more.
I have been searching for a while for good tools to split/regroup diffs in a patch series. hunk.nvim looks interesting. Do you know of similar/competing tools?
I frequently hit a problem where removing a spurious hunk from an old commit causes cascading conflicts in all subsequent commits. Are there tools to propagate hunk removal into the future without the manual conflict-resolution pain?
Thanks again!
Are you looking for solutions within git or jj?
In my experience with jj when resolving a conflict, as long as I do it in the earliest change, I will only have to do it once.
Git has the rerere setting [0] which reduces the need to resolve the same conflict over and over
0: https://git-scm.com/book/en/v2/Git-Tools-Rerere
git rerere
https://git-scm.com/book/en/v2/Git-Tools-Rerere
I can't help with your actual problem but I am incredibly curious about how/why you run into this so frequently you need a tool for it. I feel like in my 15 or whatever years of using git I have basically never wanted to remove a hunk from an old commit or anything similar.
I try to leave a good commit trail in my PRs. These are often _not_ the reality of how the code was written and originally committed, but a rough approximation of the intended steps with the benefit of hindsight.
A tool like https://github.com/tummychow/git-absorb has been on my to-try list for a while, but for now I do it by hand.
Not the GP, but I might recommend Jujutsu for that, try it and see. It does the right thing when you resolve commits, and it propagates them to git. However, I'm not sure if it'll work, try it and see.
Jujutsu is much better than git, and I've switched to it completely, but I do still use lazygit for one thing: It has better diff viewing, it separates the diffs by file and they look nicer. It's the only thing keeping me on lazygit, as jjui is much better otherwise.
Git doesn't fundamentally work with diffs (patches). It stores the complete file and generates a diff.
So you can use any diff tool you like with git, and I presume also with JJ. Look for the setting.
Edit: in git it's the diff.external setting
I know I can. I want to use jjui, but its UI isn't as good, so I use lazygit.
2 replies →
just to add to the chorus, I'm switching to jj as well. I haven't started using it in every project but it's only a matter of time I think.
That said, I do which for a more jj aware GUI. For one, it's nice to be able to quickly see diffs across a bunch of changes. I use gg for this but I'd prefer a side-by-side diff and, ATM it only has a traditional diff.
Also, watching the video of git butler, it seems like a jj UI could take a lot of inspiration. I'd love to be able to just drag changes rather than `jj rebase ...` and/or drag selections of lines.
I'd also like a nicer GUI for interactive splitting/rebasing than the TUI UI built into jj
I think a big problem with Git is that it's not opinionated enough. Every team has their own Git flow because Git makes it possible to do so and most developers love nothing more than micro optimizing every minute aspect of any work that is not the task they've been assigned this sprint (myself included), or avoiding learning anything at all (half of my coworkers) thereby leaving the decisions to people like me. I'd much prefer a tool that has one way to do things and everyone just had to "get with the program." Instead, we have this Swiss Army knife that can do anything but requires arcane knowledge of how to do things that are just slightly off the beaten path.
I'm very comfortable with Git and have saved coworkers in just a few minutes from what they thought was going to be missing days of work. But I'd much rather if they had never gotten into that situation or could easily fix it themselves. I don't like the idea of every software team needing a Git expert in easy reach just in case something goes awry.
If you could make it opinionated in one or two ways, how would you do it? I'm having a hard time thinking about situations that would be solved by this
In the past we would say google it but it's even more inexcusable today with LLMs.
And if something becomes really hard to do with git, I found that often the problem are on the project itself.
This is a good point, git is more like a very clever toolbox than an actual "version control system". You can certainly implement a vcs using git, but it doesn't exactly start out as one.