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

91–100 of 193 posts

Re: Defeating Git Rigour Fatigue with Jujutsu

#91

Post by kccqzy »

rmwaite wrote: post #59
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 remember being the big innovation over svn being merging. There were others things, obviously, but the distributed model + easy merges is what I remember.

If the big innovation over svn is merging for git, then the big innovation here is conflicts. I hate the fact that git requires you to stop everything and fix the merge conflict when you merge. I especially hate the fact that when rebasing in git sometimes it requires you to solve conflicts one by one. The big innovation here is jj does not require you to resolve merge conflicts in a timely manner; it simply records the fact that there are conflicts in the file and you go about your ways. You don't ever have to abort like `git rebase --abort` or `git merge --abort`.

Re: Defeating Git Rigour Fatigue with Jujutsu

#92

Post by surajrmal »

3eb7988a1663 wrote: post #47
stouset wrote: post #46

This seems like a lot more effort than the (to me) more natural jj workflow of maintaining the idealized series of commits plus a working commit on top. As you make tweaks and fixes you just squash the relevant parts into the already-clean history. Basically, if you don’t get into that sort of situation with commits containing parts they shouldn’t in the first place, you don’t need to do any extra work to clean them…

That is a lot of discipline up front. I am sure there are problems which are nicely bucketed, but I usually have to go with the flow and make changes as I see them. I want to keep working with the code, not babysitting version control as I focus on getting the initial version to work.

I think it comes down to your ability to plan and understand how the work can be broken down before you try solving it. I often know what every commit will look like before I ever touch the code. I do sometimes learn things and change my mind as I make changes but it doesn't often change my commit structure. I tend to work on a codebase I have 8+ years experience in though. I'm sure it doesn't work in a variety of situations though.

Re: Defeating Git Rigour Fatigue with Jujutsu

#93

Post by kaladin-jasnah »

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 commits means I have to add my commit, move my bookmark up to the branch tip (jj tug?), and then rebase the megamerge branch, versus doing nothing for squashing. I also find that when I mess up, I don't really love using `jj op log` to fix it. I want to not be in an environment where it's this easy to destroy history (I feel like git was on the other end of it).

Re: Defeating Git Rigour Fatigue with Jujutsu

#95

Post by surajrmal »

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.

A lot of humans don't currently trust agents to touch VCS today. I also find that my agent tends to be much better about dealing with jj than it is with git.

Re: Defeating Git Rigour Fatigue with Jujutsu

#97

Post by cpeterso »

paradox460 wrote: post #80
y1n0 wrote: post #66

Earlier quoted context omitted.

I make a commit and the branch doesn't follow it. Bookmark, whatever. That is never a behavior I would want. What purpose does it serve?

They added auto advance bookmarks a while ago. You configure which revset bookmarks you want to advance or not, and then it just keeps them at the "head" of a branch

Having to list all the bookmarks you would list to auto-advance in your jj config.toml is a hassle and easy to forget.

Re: Defeating Git Rigour Fatigue with Jujutsu

#98

Post by cpeterso »

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…

I name my branches for the overall task. The description of the branch’s head commit in jj status doesn’t tell the whole story.

Re: Defeating Git Rigour Fatigue with Jujutsu

#99

Post by sswatson »

skydhash wrote: post #38
jolux wrote: post #30

Earlier quoted context omitted.

There’s nothing stopping you from using separate changes to emulate the staging area if you want.

I can, but I don’t need to. jj has nothing I need, so it would be changes for the sake of changes. I’m not saying it’s bad, but people do need to realize that their struggles are theirs, not the whole world.

Not trying to tell you how to live your life, obviously, but I think “changes for the sake of changes” overstates it. For example, `jj undo` is a pure ergonomics win.

It’s been said a million times but it is really true that jujutsu’s appeal is something you feel (or don’t) after giving it a proper go. It doesn’t survive compression into the feature list.

Actually I think that property is a much bigger obstacle to adoption than what it does or doesn’t offer to the rare true git wizard.

Re: Defeating Git Rigour Fatigue with Jujutsu

#100

Post by matheusmoreira »

steveklabnik wrote: post #79
matheusmoreira wrote: post #64

Earlier quoted context omitted.

How does it just auto-rebase everything without failing though? If you edit something later commits depend on, then you get merge conflicts. Are you implying that jj just automatically handles all this?

jj allows your commits to stay in a conflicted state until you choose to resolve them. I wrote about this a month ago: https://news.ycombinator.com/item?id=47767292

I see. It doesn't deal with the conflict, it just proceeds regardless. I'm curious about how it works internally. Does it do something like commit the conflict and soft reset later?
Post reply on HN