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

311–320 of 552 posts

Re: Jujutsu for busy devs

#311

Post by voidfunc »

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 use like five commands total in Git and the rest is driven through my IDE which handles everything else. People who tell me Git is hard or recommend alternate tools are living in a different world.

Re: Jujutsu for busy devs

#312

Post by amomchilov »

tomasyany wrote: post #266

Don't want to sound old school, but git works perfectly fine. The learning curve might be a bit difficult, but afterwards everything makes sense. And let's be honest, you just need a few actions (pull, add, reset, branch, commit) to use it in 95% of the cases.

Stacked diffs are a core part of my workflow, letting me “work ahead” without being blocked waiting for reviews.

Setting them up in git is not to bad. Adding a change to the bottom of the stack, and restacking everything on top… that’s hell in git.

Re: Jujutsu for busy devs

#313

Post by normie3000 »

nchmy wrote: post #287
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…

Jj makes this effort vastly easier. Nearly frictionless.

Great. As I said elsewhere on this story, I'll suggest jj to colleagues who struggle with git.

Re: Jujutsu for busy devs

#314

Post by pjmlp »

nchmy wrote: post #308
pjmlp wrote: post #305

Earlier quoted context omitted.

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.

Nope, you get the IT validated image as per project delivery assignment, in many cases not even local, for security reasons it is a cloud VM.

Re: Jujutsu for busy devs

#315

Post by riwsky »

turboponyy wrote: post #197
stouset wrote: post #133

Earlier quoted context omitted.

The staging area is a hack in that it is its own unique concept that doesn't work with any of the rest of git's tooling without needing special, inconsistent flags for commands to target it (git stash, git reset, etc.). I use a staging area with jj! I would surmise most jj users do too. It's just a real, honest-to-god commit in the repo instead of a special snowflake. # do some work … # prepare a new, empty commit if…

Can you edit commits by adding on only parts of your "staging" area? Because that's my workflow. I produce a few focused and semantically coherent commits that I'd like to apply to the codebase, where each keeps the codebase in a working state. I might be working on more than one thing at once, but I know which commit each set of changes should "live in." An append-only log of commits is decidedly not something I wan…

Extremely amenable—my workflow shifted to match your description after I started using jj, because it makes that easier. Conceptually, it’s not “edit commits by adding on only parts of your staging area”, but “edit commits by only moving or splitting parts from another commit”, and since the working copy is a commit, it is handled by that general case instead of being it’s own thing.

Re: Jujutsu for busy devs

#316

Post by christophilus »

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 used it for a little over a week, and switched back. This was a while ago, but the main reason was my neovim setup and flow never felt as good. Maybe jj has a good neovim plugin and diff mechanism now, though?

Re: Jujutsu for busy devs

#317

Post by __turbobrew__ »

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…

How fast I can deliver value is almost never gated by my VCS, so why should I try? In total I maybe lose a few minutes a month to VCS impedance mismatch, and I am merging on average ~4-5 PRs a day.

For sure git is hard to learn for beginners and there could be an alternative which is easier to pick up (maybe jj) but for those who know how git works internally and are proficient with it I don’t see it being worth the switch.

Re: Jujutsu for busy devs

#318

Post by riwsky »

nchmy wrote: post #296
esperent wrote: post #112

Earlier quoted context omitted.

> there are generally two camps of people: those who haven't given it a shot yet and those who evangelize it. This sounds exactly like something a person evangelizing it would say.

The relevant question is, why would a stranger take time out of their life to evangelize an open source VCS tool? What other tools do people do that for? Not many. I see the most similar language and behaviour with regards to uv, which similarly revolutionized/simplified python tooling. Likewise mise, which makes it similarly frictionless to install and manage tooling and their versions across projects and system-wid…

“Trauma” is a bit much.

Re: Jujutsu for busy devs

#319

Post by koakuma-chan »

nchmy wrote: post #201
koakuma-chan wrote: post #183

jj is unusable at least because there is tooling built around git repositories specifically

jj itself is tooling built around git repos... It just works seamlessly with any git repo. And there's toppling built around jj, such as jjui https://github.com/idursun/jjui

Oh --colocate is what I needed.

Re: Jujutsu for busy devs

#320

Post by endtime »

gdbsjjdn wrote: post #302
stouset wrote: post #154

Earlier quoted context omitted.

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.

The hard part I always found without jj (and Fig before it, when I was at Google) was managing a DAG of small changes.

What's your git workflow for a change that depends on two other in flight changes? (More generally, of course, this can occur in an arbitrary part of one's change graph - which is usually not too deep, but at least in my experience, occasionally is.)

Having good tooling for this unlocked workflows I didn't know I was missing, and switching back to git when leaving Google felt like losing a limb.

Post reply on HN