Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defeating Git Rigour Fatigue with Jujutsu

ikesau.co

Post reply on HN
Print view View original

121–130 of 193 posts

Re: Defeating Git Rigour Fatigue with Jujutsu

#121

Post by BeetleB »

y1n0 wrote: post #2

I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time. Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can…

I think much of the problem with this thread is people trying to convince one way is superior/inferior.

There are just multiple different ways of working. Some ways fit some people's mental models better.

You're not going to get a definitive "jujutsu is better than git" or vice versa. You should accept that some people have no problems with what you've described using jujutsu, and likewise jujutsu users should understand that not everyone can handle jj as well as they can.

Imagine a different thread where jj users take your exact scenario, and complain about solving the problem with git. You wouldn't understand their pain, because it's not painful for you. This thread is the same, just with jj and git reversed.

Personally, I don't see the pain you have. Back when I used git a lot, if I left a branch for a few weeks, I'd forget the name of the branch and would have to list all the branches (and set an alias to sort by and list the last commit dates of each) to discover the appropriate branch name. It's really not all that different from looking at all (recent) heads. Once you get used to this, you stop naming branches - other than to share with others. And when you do share with them, you cannot push (newer) changes because only bookmarked nodes and their parents can be pushed - so just prior to pushing, you advance the bookmark. With the shells I use, it's a few keystrokes before autocomplete/fzf produces the command for me - no mental effort at all.

You definitely wouldn't advance the bookmark with each commit. Only when you need to push.

And oh man, it's so nice not to have to manage all the branches. With git, I'd routinely go and delete old branches to declutter. With jj, there's simply no need to. The same with stashes. It's really nice not having to do that labor, and simultaneously not dealing with long lists.

If this doesn't appeal to you - that's fine. You're not deficient. But understand, nor are those for whom your workflow sucks.

Re: Defeating Git Rigour Fatigue with Jujutsu

#122

Post by nemo1618 »

hu3 wrote: post #72
fragmede wrote: post #26

The elephant in the room is that I haven't had to do something complicated and manual in git by hand in a long while. I'm using AI to generate code, and further, having it commit to git and pushing and pulling and managing branches and merging for me. So for people new to software development, they can also just ask AI to deal with git, which papers over the harder parts of its UX.

This. I feel jj is some years too late. It tries to solve a human problem in an LLM era. LLMs are destined to overcome humans in code merging and change versioning (already did for me). There's little point to introducing yet another layer of indirection when LLMs just cut to the chase.

Good git hygiene is also less important post-LLMs, as the LLM can make sense of even a messy history.

Re: Defeating Git Rigour Fatigue with Jujutsu

#124

Post by stouset »

bentcorner wrote: post #114
stouset wrote: post #110

Earlier quoted context omitted.

The conflict markers are a first-class citizen in the repo. jj tells you when a commit has a conflict, and you can go edit it at your leisure. It also does prevent you from doing some things with branches in a conflicted state, like pushing them. You might not think this is that big a deal, but this also means you don’t have to resolve the entire thing in one go. Plenty of times with complicated rebases in git, I’ve…

I've come to the opinion that conflicts should be committed and merge fixes should be in another commit afterwards. Arguably even if the merge fix is trivial.

That’s almost definitionally what a merge is.

A merge conflict means that some automated tool couldn’t figure it out. But all a merge is is a commit with two parents and an accompanying diff that shows the process of combining them. A merge conflict isn’t really in any way special. It just means whatever algorithm was used couldn’t do it unambiguously without human help.

Re: Defeating Git Rigour Fatigue with Jujutsu

#125

Post by oscillonoscope »

kaladin-jasnah wrote: post #93
y1n0 wrote: post #2

I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time. Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can…

I like jujutsu simply because (despite my annoyances, which might be because I started using it 2 weeks ago) it's still faster than git. I dislike this as well. I find it easier to keep track of branches with bookmarks, but my workflow still makes things cumbersome. I am usually working with the "megamerge" branches, and I usually want to add commits to my current branch instead of squashing my edits. However, adding…

If I need to move a 'branch bookmark' around a lot, I usually just tie it to an empty commit and then rebase changes before the bookmark.

Re: Defeating Git Rigour Fatigue with Jujutsu

#126

Post by jaredklewis »

BeetleB wrote: post #121
y1n0 wrote: post #2

I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time. Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can…

I think much of the problem with this thread is people trying to convince one way is superior/inferior. There are just multiple different ways of working. Some ways fit some people's mental models better. You're not going to get a definitive "jujutsu is better than git" or vice versa. You should accept that some people have no problems with what you've described using jujutsu, and likewise jujutsu users should unders…

It’s only natural to want to defend one’s preferences with these things. Because unlike with some other preferences, such as what IDE, operating system, or terminal emulator you use, version control systems must be shared.

If it is like you say and different people are just inherently more or less suited to different paradigms, then not everyone can be happy.

Re: Defeating Git Rigour Fatigue with Jujutsu

#127

Post by [deleted] »

jaredklewis wrote: post #126
BeetleB wrote: post #121

Earlier quoted context omitted.

I think much of the problem with this thread is people trying to convince one way is superior/inferior. There are just multiple different ways of working. Some ways fit some people's mental models better. You're not going to get a definitive "jujutsu is better than git" or vice versa. You should accept that some people have no problems with what you've described using jujutsu, and likewise jujutsu users should unders…

It’s only natural to want to defend one’s preferences with these things. Because unlike with some other preferences, such as what IDE, operating system, or terminal emulator you use, version control systems must be shared. If it is like you say and different people are just inherently more or less suited to different paradigms, then not everyone can be happy.

[deleted]

Re: Defeating Git Rigour Fatigue with Jujutsu

#128

Post by BeetleB »

jaredklewis wrote: post #126
BeetleB wrote: post #121

Earlier quoted context omitted.

I think much of the problem with this thread is people trying to convince one way is superior/inferior. There are just multiple different ways of working. Some ways fit some people's mental models better. You're not going to get a definitive "jujutsu is better than git" or vice versa. You should accept that some people have no problems with what you've described using jujutsu, and likewise jujutsu users should unders…

It’s only natural to want to defend one’s preferences with these things. Because unlike with some other preferences, such as what IDE, operating system, or terminal emulator you use, version control systems must be shared. If it is like you say and different people are just inherently more or less suited to different paradigms, then not everyone can be happy.

> version control systems must be shared.

This whole thread is about working with git coworkers while using jujutsu, and it was in that context that I wrote my comment: Namely that most who prefer jujutsu happily work with their colleagues who use git in precisely the scenario the OP mentions and don't see why the OP finds it painful. The OP and others should accept that reality.

> If it is like you say and different people are just inherently more or less suited to different paradigms, then not everyone can be happy.

If you force everyone to use git, of course not everyone will be happy.

If you force everyone to use jj, of course not everyone will be happy.

Thankfully, the whole point is git and jj users can interoperate without needing to care what the other is using. So yes, not only can everyone be happy, but everyone is happy! This isn't a hypothetical - it's a reality. It's the reason so many use jujutsu at work.

Re: Defeating Git Rigour Fatigue with Jujutsu

#129

Post by rixed »

kccqzy wrote: post #63
y1n0 wrote: post #2

I don't get why people like jujutsu. I tried it for a while but I work with a quite a few people in the same repo and I need easy named branches that keep up with commits. For all the many problems in git, branches are dead easy. That was the big innovation over svn at the time. Last time I tried jj, branches were an extremely laborious process to keep up to date. I don't see how people that aren't working alone can…

You don’t need easy named branches. Naming branches is a chore: since you already spend time writing commit messages, branch names are just a summarization of your commit messages but with more character restrictions. That’s why I always use jj’s automatic commit identifiers. They are short and I don’t waste brain cycles naming things that are ephemeral. When I push, I let jj automatically creates, updates, and delet…

  branch names are just a summarization of your commit messages
What kind of dev workflow leads to this surprising opinion?

Re: Defeating Git Rigour Fatigue with Jujutsu

#130

Post by LoganDark »

y1n0 wrote: post #70
LoganDark wrote: post #31

Earlier quoted context omitted.

I don't try to reimplement the git workflow on top of Jujutsu. I like it because I can let go of a bunch of annoying noise that I needed in Git. I like it because rebases don't have to be synchronous and modal. I like it because I can easily edit history, rearrange the commit graph, change commit descriptions, duplicate, and so much more, and even remotely (without having to checkout first). There's so much to love t…

That's great that it has things you like. I don't do rebasing, except on MRs where I've come to prefer squashing the branch being committed. But I don't rewrite history. It's history. While I can understand people have reasons to do it, the reasons have never resonated with me. I'd rather spend my time getting new work done and not polishing work I've already done.

Using jj is easier when your whole team uses jj. When the rest of your team uses Git, it's understandable that the pains of keeping up with Git-isms (e.g. constantly updating branches) start to become quite inconvenient. Though once you get used to jj they're not much of an inconvenience at all, they are still extra steps compared to raw Git. So if jj doesn't have any other inherent value to you it makes sense not to make the jump.

To me, jj has inherent value because I do a lot of things raw Git makes difficult or impossible. For example, https://github.com/LoganDark/fabric-template supports every point release of Minecraft since 1.14, and mods like https://github.com/LoganDark/debrand derive from it. I often rewrite the history of the template with configuration improvements and then rebase the histories of each mod on top of it.

This keeps my project setup consistent throughout versions, and consistent between mods, and allows all my mods, across all supported versions, to benefit trivially from all improvements I make to my global template. This workflow is either not possible with git or would require slow, ugly and fragile scripts.

Post reply on HN