Live data from Hacker News

Jujutsu for busy devs

maddie.wtf

331–340 of 552 posts

Re: Jujutsu for busy devs

#331

I legit ask myself how many folks avoid Github Desktop for some dogmatic reasoning equivalent to "having an UI makes it worse", when it does the core of common flows extremely easily and clear. To be clear where it ties to this post: it makes git far more convenient with nearly 0 learning curve.

My thought is, if a GUI like GH Desktop makes it hard to use Git, then your workflow is too complicated. Version control doesn't have to be complicated. But a lot of that is upstream decisions about how you structure your work as a team.

Re: Jujutsu for busy devs

#332
post #296

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…

> What other tools do people do that for?

Text editors, programming languages, shells, VCSs, nix/guix…

Re: Jujutsu for busy devs

#333
post #251

Earlier quoted context omitted.

> It is more like "you should use jj because then you won't have a lot of problem with git that you'd need git to solve" I don't have a lot of problems with git that I need to solve, that's the thing. 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? :-) > It is not. There are plenty of example on this page. The problem is that many examples, to…

> I don't have a lot of problems with git that I need to solve, that's the thing. And I don't get why people keep trying to convince me You are in *forum* in a post *about jj* saying there is no reason to use jj. We are just interacting as you'd expect in forum. If you don't see any reason to use anything else and don't want to hear anything about it steer away from these posts. No one is trying to convince you perso…

> You are in forum in a post about jj saying there is no reason to use jj

I honestly am not. I am genuinely interested. Everytime there is a post about jj I'm about to try, and then I see a comment like yours, saying "with jj you just use the intuitive syntax `jj git push -r '(trunk\(?.\).x#@ | @@.^)'`, which is a lot simpler than knowing about this weird concept of stash" and it makes me think that maybe, I'll try again next time.

Re: Jujutsu for busy devs

#334

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.

If you work in a team you need to understand rebasing and squashing, unless you can convince team to never use these features. A lot of people are religious about rebasing, "clean" commit history. But it's pretty much incompatible with several devs working on a single branch. I.e. when you work on something complex, perhaps under time pressure, git habits bite you in the ass. It's not fine.

A lot of the time, multiple devs working on a single branch can be avoided via different decisions made upstream about work that needs done. If my job included more git wrangling as one of my daily tasks I would probably hate my job.

Re: Jujutsu for busy devs

#335
post #293

Earlier quoted context omitted.

This is the age-old issue of how you describe something that has enough small improvements to result in one big one. There's no single thing that someone can say to convince you to switch to jj, because there's no single thing that you can do with jj that you can't with git. It just has a thousand little improvements left and right, that make it a joy to use. That just results in less friction, and in you doing thing…

I've started, in this thread, likening it to Plato's Cave - people who are just using git are just seeing/using a blurry facsimile/projection of actual reality/possibilities. It's not a perfect analogy (jj is, I suppose, the projection, and people are chained in the cave), but it makes the point that there could be so much more. The matrix or people happily in a cult would be similar analogies. Perhaps even Stockholm…

This is exactly why it feels like evangelism: "people who don't love jj haven't seen the light/are uninformed/live in the dark age/must be in a cult".

That kind of rhetoric makes me want to say "don't tell me I'm stupid if you are the one finding it hard to switch between git branches".

Re: Jujutsu for busy devs

#336
post #254

Earlier quoted context omitted.

And I totally agree! And if jj works better for you, please use it! My point is just that I am yet to find a convincing example that would suggest that jj would improve my workflow. If people find it hard to stash a change, I don't tell them that they shouldn't get their shit together and not use jj. But I don't find it hard to stash a change, so why do I feel like jj evangelists try to convince me that something is…

This is the age-old issue of how you describe something that has enough small improvements to result in one big one. There's no single thing that someone can say to convince you to switch to jj, because there's no single thing that you can do with jj that you can't with git. It just has a thousand little improvements left and right, that make it a joy to use. That just results in less friction, and in you doing thing…

This is one of the few comments here that make me feel like I should just try jj. Thank you, this is useful :-).

Re: Jujutsu for busy devs

#337
post #336

Earlier quoted context omitted.

This is the age-old issue of how you describe something that has enough small improvements to result in one big one. There's no single thing that someone can say to convince you to switch to jj, because there's no single thing that you can do with jj that you can't with git. It just has a thousand little improvements left and right, that make it a joy to use. That just results in less friction, and in you doing thing…

This is one of the few comments here that make me feel like I should just try jj. Thank you, this is useful :-).

You're welcome! I've honestly really started doing stuff that git conditioned me into think I just didn't need, just because it made them hard to do.

Re: Jujutsu for busy devs

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

>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. Agreed. Having used SCCS, CVS, Subversion, VSS, Perforce, Clearcase, Accurev (the weirdest of the lot), Mercurial and Git, I'll move when the market decides what has critical mass and my job needs it. jj feels a bit like learning a Dvorak keyboard and then being in an office of qwerty. Jobs wa…

I mean, Git was a massive improvement over those other systems though. It was absolutely worth learning, and worth pushing companies to adopt. (Same with Mercurial, obviously.)

Re: Jujutsu for busy devs

#339

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.

git rebase -i lets you reorder commits easily, as long as they don’t have conflicts. If they do, you’re in for a rough time. I struggle to see how a vcs could help with that, even if I’d be happy to be proven wrong.

One cool tip to help with conflicts is the revert trick. If you have a conflict that you need resolved earlier in your commit chain, you can commit a cleanup that hides the conflict, revert it instantly and reorder the commits with interactive rebase to insert the revert first. It’s a bit hard to explain without an example, once you’ve tried it you will understand.

Post reply on HN