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

301–310 of 552 posts

Re: Jujutsu for busy devs

#301

Post by arunix »

sngz wrote: post #139
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…

I always go back to using mercurial for personal projects. Better than both

Can you say more about how it's better than both?

Re: Jujutsu for busy devs

#302

Post by gdbsjjdn »

stouset wrote: post #154
palata wrote: post #143

Earlier quoted context omitted.

> 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…

For a lot of people, making small and tightly-focused branches that are easy to review and merge is very important. This is where jj excels. Especially if you find yourself often doing large chunks of work between convenient checkpoints, but you still want to create commits as if this work was all done in tiny and discrete chunks. It's also very helpful if you're the kind of developer who makes lots of unrelated chan…

I follow this methodology but I just ... use git? The hard part of making multiple small PRs is usually wrangling someone to actually review them, or following whatever process management has decided is necessary.

Re: Jujutsu for busy devs

#303

Post by nchmy »

Disposal8433 wrote: post #115
esafak wrote: post #61

Earlier quoted context omitted.

Do you use an IDE with git support but not jujitsu? I do (intellij), and I'm not sure how useful it would be.

I've always hated the git CLI, and that's why I used Jetbrains tools or Sublime Merge. Now that I switched to jj (colocated with a get repo, very useful), I went back to using the CLI again for jj and I don't miss the graphical tools.

Try jjui. It's an amazing TUI

Re: Jujutsu for busy devs

#304

Post by stavros »

nchmy wrote: post #289
stavros wrote: post #260

Earlier quoted context omitted.

Can you go into some detail on how you do this? I use jj but it sounds like you make a change and then split it up into more changes after the fact, which I'm not familiar with yet.

I have a bad habit, even still, of just working in one monster commit. It took me a few months to realize that I could use jj split to move specific files to a different commit. And then I'd sometimes squash them into related commits, rebase to move them around etc... But I just discovered interactive split, which lets you move specific lines and sections from different files in a commit to a different commit. So I'v…

Interactive split?! Very interesting, I'll look into that, thanks!

EDIT: I love it.

Re: Jujutsu for busy devs

#305

Post by pjmlp »

nothrabannosir wrote: post #249
pjmlp wrote: post #241

Earlier quoted context omitted.

Usually I am pretty much against snowflake approaches in project delivery, setup should be the same for everyone, as people change roles across projects routinely.

The delivery is the repo and its commits. Recommending a setup is one thing, but enforcing particular tools has about the same level of appreciation among any senior dev I know as enforcing a keyboard model.

Those senior devs don't work on the kind of industry that I work on, enterprise consulting with high attrition of team members, and possible offshore teams.

This kind of industry work needs factory line mindset, there aren't special knobs for someone on the sidelines working on the software rolling carpet, which granted isn't for everyone.

Re: Jujutsu for busy devs

#306

Post by beanjuiceII »

palata wrote: post #256
whatagreatboy wrote: post #240

Earlier quoted context omitted.

How much time do you spend resolving merge conflicts between multiple team members?

In good approximation, I would say around 0 minute a week. I guess it could happen that it takes a few minutes, but I don't remember last time it happened.

yea i am really confused by all these issues people are saying they have myself..stashing merging etc...and what is crazy is we migrated large teams of programmers who's only experience with version control before git was microsoft TFS and and everyone is easily and happily chugging along. Now most of these people use gui tooling for managing git, but so what everyone gets it done with no issues or complaints with many projects big and small. we even have non-devs using it. I get jj might have some life improvements for some niche groups of people but i really have to wonder if they are the type of people who purposely make their life more complex

Re: Jujutsu for busy devs

#307

Post by nchmy »

darthrupert wrote: post #203
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…

You can consider your perfect conversion rate now broken; I tried jujutsu on a personal project and found it to be a hassle without any upsides. I believe your perception is flawed because the people who just try it and throw it away don't tend to talk about it because it's not popular enough to warrant even a twitter comment. This is the first time I got the impulse to share this but only because you claimed a rathe…

Care to elaborate on the hassle and lack of upsides? Have you considered that you simply didn't give it a fair shake or were holding it wrong?

Re: Jujutsu for busy devs

#308

Post by nchmy »

pjmlp wrote: post #305
nothrabannosir wrote: post #249

Earlier quoted context omitted.

The delivery is the repo and its commits. Recommending a setup is one thing, but enforcing particular tools has about the same level of appreciation among any senior dev I know as enforcing a keyboard model.

Those senior devs don't work on the kind of industry that I work on, enterprise consulting with high attrition of team members, and possible offshore teams. This kind of industry work needs factory line mindset, there aren't special knobs for someone on the sidelines working on the software rolling carpet, which granted isn't for everyone.

Can you choose your own IDE? if so, you should be able to choose how you manage git locally, such as with jj.

Re: Jujutsu for busy devs

#309

Post by nchmy »

kirici wrote: post #188
WhyNotHugo wrote: post #181

The main things that drives me crazy about jj is that all changes are always staged implicitly. This is what SVN did back in the day, and git was a huge improvement by staging changes explicitly. I almost always have more changes in my repository that those which I want to include in the next commit. With git, I just add the changes I want. With jj (and svn), there’s not obvious way around it—you have to manually cop…

You could disable autom snapshots or use `jj split -i`, which I use almost exclusively

I just discovered interactive split last week. Absolutely beautiful.

Re: Jujutsu for busy devs

#310

Post by 1718627440 »

notmywalrus wrote: post #299
1718627440 wrote: post #248

Earlier quoted context omitted.

It's just that I'm fine and also the features seam to amount only to a change in usage not in actual new features. In this case if you want to use commits instead of a stash, then you can do that just fine in git. It's also that I want my commit hashes to be stable (because I cross-reference them) and it sounds like they wouldn't in jj, because it is kind of rebase-y?

I would call `jj absorb` a new feature (new if coming from git, I believe the idea was taken from hg). It moves diffs into the closest ancestor that touched those files/lines. Very useful for addressing reviews, then just `jj absorb` and watch them get squashed into the correct location. This gets even better with octopus merges (known in the jj community as "megamerges"): open up 5 branches at the same time, address…

I do use git absorb, but its true, you have to install it.

I have never tried git absorb across merges, no clue if that works.

Post reply on HN