Comment by jlokier
2 days ago
> You can just mess around and make it presentable later, which Git never really let you do nicely.
I'm surprised to read that, because that's how I've always used Git (and GitHub).
That's what I've understood to be good practice with Git, and it was liberating compared with what came before. One of the nicest things about Git is you can throw things in locally without worrying about how it looks, and make it presentable later.
I also did that with git, but it's no comparison in ergonomics. For instance, "move this hunk two commits up" is a task that makes many git users sweat. With jj it's barely something that registers as a task.
You sweat because you are working with the CLI. Git is intrinsically "graphical". Use a good GUI client or higher level interface (maybe jj) to manipulate git graphs --- stop worrying about "how" (i.e. wrangling with CLI to achieve what you want) and focus more on "what".
GitButler from OP also allows you to do this incredibly easily. This and stacked commits is IMO their main selling point.
> For instance, "move this hunk two commits up" is a task that makes many git users sweat.
Citation needed. You split the commit anyway you like, e.g. with the mouse or using cursor movements or by duplicating and deleting lines. Then you move it with the mouse or cursor or whatever and squash it into the other commit. Maybe some people never intend to do it, but then these probably also don't want to learn JJ. I guess this is more of a selection bias, that these that care about history editing are also more likely to learn another VCS on their own.
I'm one of the git users who would sweat. Can you explain a bit (out link relevant docs) how I might split a commit up, and move it?
3 replies →
The problem put simply is that git doesn't support concurrency. Even if you use worktrees, git has a global lock for repo interaction.
https://www.felesatra.moe/blog/2024/12/23/jj-is-great-for-th...