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

Jujutsu for busy devs

maddie.wtf

Post reply on HN
Print view View original

401–410 of 552 posts

Re: Jujutsu for busy devs

#401

Post by steveklabnik »

1718627440 wrote: post #267
KingMob wrote: post #252

Earlier quoted context omitted.

That's still true in jj, too. But instead of commits, most of the time you're working with (the not greatly-named) "changes", which are a conceptual history of related commits. E.g., a single change ID points to the most recent commit in a list. As long as you keep editing on a change, it keeps accumulating commits under the hood. When you move to another change (via `jj commit`, `jj new`, etc), all your new commits…

Ah, so when people here talk about changing commits they are actually talking about changing changes (nicely named, indeed)? What happens when you merge or split changes with the change history? It sounds a bit like applying a VCS on top of a VCS.

Yeah so people will be a bit loosey-goosey with the terminology. But all of these changes are immutable, that is, when you change a change, you’re generating a new commit. “A VCS on top of a VCS” isn’t a terrible way of thinking about it: imagine if every commit in your repo had its own history.

Merging is making a change that has more than one parent. You can then resolve any conflicts within that change.

Splitting a change into two will update one commit with one half and make a new change with the other half.

Re: Jujutsu for busy devs

#402

Post by deredede »

nchmy wrote: post #204
deredede wrote: post #118

Earlier quoted context omitted.

> This is excruciating in git if you ever need to make a fix to an earlier PR because you have to manually rebase every subsequent change. Spreading the word about `git rebase --update-refs` that will automatically update any branches that point to commits along the path (very useful with stacked branches). It is less convenient than what jujutsu offers (you need to know the branches to update, where jujutsu automati…

There isn't really any "can't switch to another tool" when it comes to git + jj. You can use it today without anyone on your team knowing - other than that your PRs suddenly became much cleaner

Some people can't install arbitrary software on their employer's hardware.

Re: Jujutsu for busy devs

#403

Post by Nzen »

do_not_redeem wrote: post #7
Lyngbakr wrote: post #5

I feel pretty dense, because I still struggle to get my head around automatically adding changes to a revision. Sometimes, I'll make a change locally to a file that I'll use during the development process that I have no intention of committing. With regular git, I never stage that file so there's no danger of accidentally pushing my change to the remote repo, but it seems with jj I'll need to somehow unstage that cha…

If you want this workflow, you can treat jj's `@` (nominally equivalent to git's HEAD) as the git index, then at commit time, manually squash changes to `@-` just like you would with `git add --patch`.

When I've asked about using a jj stage, that's the workflow people pointed me to, as described in this tutorial [0]. I've not tried it, nor jujutsu, but I felt it worth pointing at a concrete example to allay or stoke fears of people on the fence.

[0] https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...

Re: Jujutsu for busy devs

#404

Post by stouset »

UK-Al05 wrote: post #379
normie3000 wrote: post #271

Earlier quoted context omitted.

> It's because what you see as the inferior approach involves less effort and friction for the developers. I can see that. From the other side of the PR though, it involves significantly _more_ work from a reviewer. The "red tape" of separating commits and opening separate PRs should be removed by the team. The effort of separating commits and opening separate PRs is minimal once you're comfortable with the tools. I…

Reviewers don't want to navigate 33 tiny PRS either. The best way of getting changes is through is simply sitting down and talking with the reviewer. Most of these small PRS, splitting things, creating elaborate stacking systems are just technology hacks around a social/process problem. I've seen people make more of a mess trying to split pr's up where they are so fine grained its silly and actually had dependencies…

> Reviewers don't want to navigate 33 tiny PRS either.

As opposed to one 33-change PR? Yes, absolutely yes they do.

I probably don’t have time to review a giant PR like that. If I do, I feel guilty asking for fixed in one part when 31 of the changes are great. Why are we holding up all these improvements for one or two small concerns? We can merge and just fix those later. Except that never happens.

I probably have time to review eight one-liners. My other coworker has time for five. After lunch I can quickly check out another seven. Over the course of the day all 33 get reviewed and merged as time allows.

Re: Jujutsu for busy devs

#405

Post by lysp »

eulgro wrote: post #202

I've never tried jj, but recently I discovered lazygit which in my opinion comes pretty close to perfection. Rebasing can be done instantly (reorder commits, fixups, squash), I can extract and reverse custom patches from previous commits, I can partially stage files, undo. One think I like is that it explains what it does in terms of git commands. So it helps a little to have a good git mental model, and as such I gu…

There is lazyjj which follows a similar theme. Haven't used enough of either to give a good comparison other than lazyjj being earlier in its journey.

Re: Jujutsu for busy devs

#406

Post by andrewaylett »

nchmy wrote: post #363
stavros wrote: post #304

Earlier quoted context omitted.

Interactive split?! Very interesting, I'll look into that, thanks! EDIT: I love it.

Haha, fantastic. Also, if you didn't discover yet, you can use the arrow keys to unfold the different files and sections. Then select what you need, split the rest to new commit. As you know, even when just using the most basic functionality (new changes, merges, rebases) of jj, it's amazing. But then you just keep discovering other features and workflows - none of which require any incantations - that make it that m…

If you end up with a commit that's a number of small fix-ups to files edited in earlier commits, `jj absorb` will push changes up to whichever (mutable) commit last modified the file they're in.

Re: Jujutsu for busy devs

#407

Post by forrestthewoods »

stouset wrote: post #140
forrestthewoods wrote: post #98

Earlier quoted context omitted.

Some people love to tinker and fine tune their tools to behave exactly like they want. I am not one of those people. I hate it. It does not spark my joy. Most people use the default for most of their tools. It’s why Google pays Apple over $20 billion per year to be the default search engine. Because defaults matter.

FWIW, I am also one of those people who does not want to fine tune their tools. I want my tools to work well out of the box. > I’ve only tried it solo hobby projects. If I can surmise a bit, this is probably why it's never felt "worth it". I'm guessing that for a hobby project you don't really care that much about crafting small, easily-digestible PRs or keeping a clean history. `git commit -a` every now and then is…

I use Sapling at $DayJob. It’s pretty good and I largely like it. jj seems much less friendly for most operations. Although jj’s merge conflict stuff is appealing (in theory).

Re: Jujutsu for busy devs

#408

Post by riwsky »

kadhirvelm wrote: post #371
riwsky wrote: post #360

Earlier quoted context omitted.

It’s both. Their CLI has a lot of overlap with what you’d use jj for (rebasing, amending, etc), but does basically everything worse other than “creating stacked PRs”. Slower; refuses to work from a detached HEAD; gets confused more easily by changes on the remote.

Sounds like your opinion is jj is easier and faster? Would you say that’s true for new developer onboarding too?

I’ve never onboarded or successfully convinced a colleague to use jj. But roughly once a month I find myself helping someone escape git hell that would either be easier to solve or avoided entirely with jujutsu. I’m not speaking hypothetically: I will solve the problem locally while waiting for them to slog through whatever merge conflicts or stash/unstash dances.

But the graphite CLI’s stacked PR review is a killer app. Our team uses it, but treats the rebase-centric workflow as the price of stacked review, instead of a mental model to leverage. I end up using jj but with a helper script to set up graphite’s branch tracking whenever I want to submit a stacked PR.

I also was always a git CLI person. I’d do diffs and resolve conflicts in a proper editor, I wasn’t crazy—but I know that changing just my mental model is less work than it’d be to change the UI habits as well.

Re: Jujutsu for busy devs

#409

Post by gabrielgio »

palata wrote: post #353
gabrielgio wrote: post #341

Earlier quoted context omitted.

> I honestly am not. You literately are, look at you comments. > I am genuinely interested. If you are interest in learning you should take people words on good faith, my comment on "jj git push -r '(trunk()..@ | @::)'" is complex operation to update many stacked PRs not compared to local git index operations. Also in my comment I mentioned revsets and the "-r". It is a language to query logs which you should've chec…

> just to bash on jj for some reason Actually, to be blunt (you're already offended anyway): what I'm saying is that I find (personal opinion) that many evangelists here (you included) don't sell jj really well. If so many people are actual fans of jj, there must be something there. I'm just struggling to find it between the "you're probably too dumb to understand a stash so you should use jj" and the "let me explain…

My initial rant to your comment was about this:

> And I don't get why people keep trying to convince me that I do. It's about me, my opinion should have some value, right? :-)

I have no problem whatsoever if you don't like jj or use git or whatever else you like.

Let's paddle back:

- you are in post about jj

- you comment why you don't like jj

- I comment why I like jj

- you post that.

Like, what is your intention here? If you don't have good faith into trying to understand the tooling, how would it fit your workflow and deflects everything with "I know git, git works, don't tell me to use something else" what is your goal here?

My problem is not your opinion on the tool, is how you approach the debate.

Re: Jujutsu for busy devs

#410

Post by kyawzazaw »

palata wrote: post #143
stouset wrote: post #33

For anyone who's debating whether or not jj is worth learning, I just want to highlight something. Whenever it comes up on Hacker News, there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. You will be hard-pressed to find someone who stuck with it for a week and decided to go back to git. You will not find a lot of people who say they switched but just stayed out…

> For anyone who's debating whether or not jj is worth learning I don't have any productivity issues with git, like... at all. It's not like I spend an hour running git commands every day. I can totally imagine that some people spend their day manipulating repos with git, and jj is better for them. But that's not my case, and git is already everywhere. To me it sounds like telling me: "You HAVE TO move to bim , the b…

I feel like it's cat vs bat.

bat just is more useful even if you didn't have issues with cat

Post reply on HN