Comment by tcoff91
3 months 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.
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.
The problem with an optionated tool that mandated a specific workflow is that people that can't follow this workflow can't use the tool
This follows the Unix principle of "provide mechanisms, not policy" (as I remember from the esr book on Unix philosophy - <imagine a link here>). Git provides mechanisms for version control and it's up to users, projects, organisations, etc to set up policy. That's because mechanisms are more universal, and policy changes with the whims of the stakeholders
(I actually agree that tools that mandate a workflow are more enjoyable. Not everyone needs to use the same version control and different DVCSes can or could be interoperable like git and jj are)
Yeah, I think we could use a little more of "not trying to be everything for everyone". If more opinionated tools meant there were five or ten VCSes in common use rather than 1 or 2, I think that would be a better world.
1 reply →
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.
Makes me wonder what other tools could be implemented on top of git, besides a vcs.
I’m sure I’m not the first one to have that thought. So I’m curious what other tools and systems people have built in top of git.
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.
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
Actually, the more I think about it, the more I realize the problem is that Git is too opinionated about a bad idea: attempting to make a DAG feel like a linked list in order to make it "easier" to use from the CLI because CLIs make it way too hard to visualize DAGs (don't come at me with your CLI DAG viz. Even the best ones are strictly inferior to the simplest GUI DAG viz).
There are really only two things I care about: the state of the files on disk and the state of the index. And I really only care about where I am and where I want to go, everything else in the middle is noise.
To me, the staging area isn't "real", it's just a tool for working with the other two. Git doesn't need to pitch a hissy fit about editing history. Allowing easy edits of history would obviate the need for the staging area. But because they called it "history", now we have emotional responses to the concept of editing it, like we're somehow committing political revisionism.
But the existence of the staging area and the attempt at making the DAG look linear makes reseting ridiculous. Every time I need to do some kind of reset that isn't --hard, I have to read my Git GUI's descriptions of what each type does, and yet somehow it still doesn't have the combination I actually want half the time. All these named reset types could just be two separate reset commands, both pointing to a commit, one resetting the files on disk, one resetting the index. Sometimes I end up having to do a two step reset of a combination of hard forward then soft backwards to get what I want.
Similarly, all the different merge strategies are dumb. None of them ever do the right thing. I'm always getting stupid shit like new blocks that insert a new ending curly brace after the previous block, followed by the new block body, then the original ending curly brace from the old previous block. Half the time I just use the reset hard/soft to then manually review changes to enact a manual merge rather than trust merge to do anything reasonable.
Sacred history makes it way too hard to organize commits in any logical way. I want my VCS to be a super-powered UNDO. I don't need it to be an audit log of who did what and when (auditability only matters for releases so why do I have to be saddled with it minute by minute?). I basically want to be able to edit two or more commits in a sequence as easily as I currently can edit the staging area, so I can easily guarantee ordering of changes to partially related modules that I'm working on together. C depends on B depends on A. I want to be able to work on all three at the same time, but make sure all changes to A come first, then B, then C, and I want to be able to do this incrementally over the course of the day, rather than all at once when everything is perfect.
But this fetish of not changing history even though we can totally change history biases all other Git tooling to attempt to appear like it operates in linear history. Like how there's the HEAD pointer that can be offset; uuuh, what happens if that offset reaches a fork (I've never tried, the poor DAG experience of the CLI has kept me in GUIs which makes the HEAD pointer completely unnecessary). Or how log is basically unreadable.
Don't even get me started on submodules vs subtrees. I have to get to work.
2 replies →
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
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.
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.
2 replies →
I am often responsible for landing branches created by colleagues who are less disciplined about their diff cleanliness than me. Very often, attempting to regroup a spurious change from an early commit to a separate "cleanup" commit results in a long conflict hell.
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 →
I've thought about using https://github.com/dlvhdr/diffnav for that
This looks very interesting, thank you!
also just to add that I've noticed that `jj` comes way easier and more intuitive to newbies I've mentored. Just yesterday I told a friend to commit his changes and he just wanted to do `git commit` (without remembering to do `git add` first). This made me realize we should just install `jujutsu` for him and he's been committing very diligently afterwards. Can recommend trying this with any people you mentor/teach.
That's also my opinion, that jj should be easier for juniors to pick up. However, I felt like there's a lack of learning material targeted at people without prior VCS experience. That's why I wrote "Jujutsu for everyone": https://jj-for-everyone.github.io/.
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
You can use VisualJJ to rebase via drag & drop, split interactively etc.
https://www.visualjj.com - I'm building it and would appreciate any feedback!
> 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).
How about tig?
ooh that's interesting, wonder if that works better than git eorktrees when playing with multiple AI agents