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

71–80 of 552 posts

Re: Jujutsu for busy devs

#71

Post by oxidant »

0cf8612b2e1e wrote: post #8
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…

No that is correct, and also a habit I am trying to break. The reasonable argument is that we should stop running code with untracked state. Either the changes are important and should be committed or not. Otherwise you are recording code versions that never truly existed during development. Where this gets extra sticky for me is tooling which refuses to distinguish repo wide config vs a local only version. VSCode be…

Counterpoint: Why should my println debugging get committed? They're not "important" for the final product but important for development.

Re: Jujutsu for busy devs

#72

Post by doritosfan84 »

dcre wrote: post #31
doritosfan84 wrote: post #3

I’ve been trying unsuccessfully to convert my team to jujutsu. I feel like what would be great is a page that really shows some common but complicated operations in git and how much easier they are in jujutsu. Something like the elevator pitch here but expanded on without the depth of Steve’s tutorial. Maybe what I need to do is do a demo so people can see and ask questions.

Not a whole list of operations, but this comparison of one common operation between jj and git is what made it click for me. https://lottia.net/notes/0013-git-jujutsu-miniature.html

Thanks. This is a really good one. It outlines an operation that would resonate well with most developers and clearly demonstrates how much simpler, easier, and faster this is in jujutsu vs git. I think most devs just wouldn't even bother to do it in git, they'd leave the test out of order and call it a day.

Re: Jujutsu for busy devs

#73

Post by steveklabnik »

frizlab wrote: post #69
steveklabnik wrote: post #36

Earlier quoted context omitted.

You can also configure jj to use whichever colors you'd like, in either the 16 or 256 color space: https://jj-vcs.github.io/jj/latest/config/#custom-colors-and...

Of course! But why even bother when everything I have to do I can do with git without any problems?

I never said you should. If you like git, use git. One of the nicest things about jj is that it doesn't require others to use it.

Re: Jujutsu for busy devs

#74

Post by frizlab »

sunshowers wrote: post #52
packetlost wrote: post #37

Earlier quoted context omitted.

> with git rebase -i you can't decide to do something else in the middle of the rebase You absolutely can, to some degree. At any point in an interactive rebase you can just make your changes and do a normal `git commit` then do `git rebase --continue` along on your merry way. Unless you're talking about suspending the rebase and like switching branches, messing around, and then resuming the rebase, which is kind of…

I do mean suspending the rebase and going to do something else, yes. It's a weird thing to do in git , because the conditions that git creates makes it weird. It is completely natural with jj, because jj doesn't have any modal states at all. (This is one of the key reasons jj is both simpler and more powerful than git — no modal states.)

Modal states are actually good IMHO.

Re: Jujutsu for busy devs

#75

Post by frizlab »

landr0id wrote: post #59
jackblemming wrote: post #2

I must be getting old because I really don’t think git needs a simplified model. But hey, if people find value from this, more power to them. The blog is well written too.

Honestly one of the biggest selling points of jujutsu for me is its `op log`. You can fuck up your repo in git and that's it -- you're screwed. Or you find some extreme magic on the internet that saves you. With jj you just "jj op undo " and you're fine. Editing prior commits is also pretty easy, which in turn makes fixing merge conflicts pretty easy too.

Like… reflog?

Re: Jujutsu for busy devs

#76

Post by stouset »

packetlost wrote: post #35
stouset wrote: post #22

Earlier quoted context omitted.

Let's say I have five commits in a row ready to go, but they should be reviewed and merged one-by-one. Upon review, I need to make a change to the first commit. How much work do you think this would be in git? How much of a pain in the ass do you think it would be if a later change conflicted with this earlier change? It is essentially zero work in jj. I `jj edit` the revision in question, make the change, and `jj pu…

It's really not a lot at all. The weakness is in "forge" tools like GitHub that add a PR/changelist abstraction on top of git and don't support sequences of patches. If you're using just commits and maybe (mailed) patches you only do a single `git rebase` (with -i if you want) and you're done. Unless jj is literally magic and can automatically fix conflicts, I can't see how it would actually reduce the work involved…

I'll be honest, it's been so long at this point since I've used git that it's hard for me to remember the exact details of many of the challenges. I know that I avoided a lot of workflows I wanted to do because of the complexity and mental overhead, and the scenario I described was absolutely one of them. Maintaining a stack of changes that needed to be merged one after another was painful if there were any unexpected hiccups along the way. Now it is painless.

Arbitrarily-complicated rebases just happen automatically with jujutsu. Inserting, moving around, and directly editing commits are first-class operations, and descendants automatically rewrite themselves in-place to incorporate changes made to their parents. Rebase conflicts are also first-class citizens so they don't block you and force you to deal with them right now or in any particular order. Having to rebase seven related conflicts one-after-another is no longer a thing, nor is realizing you fucked something up halfway through and having to restart.

Coming from git it honestly feels like magic even if it strictly isn't. It genuinely hard to understand how much unnecessary toil git makes you put up with on a day to day basis until you suddenly don't need to deal with it any more.

Re: Jujutsu for busy devs

#77

Post by dcre »

doritosfan84 wrote: post #72
dcre wrote: post #31

Earlier quoted context omitted.

Not a whole list of operations, but this comparison of one common operation between jj and git is what made it click for me. https://lottia.net/notes/0013-git-jujutsu-miniature.html

Thanks. This is a really good one. It outlines an operation that would resonate well with most developers and clearly demonstrates how much simpler, easier, and faster this is in jujutsu vs git. I think most devs just wouldn't even bother to do it in git, they'd leave the test out of order and call it a day.

Yep, I think that's right. As the other reply says, this is part of what makes it hard to explain. If you told me jj makes it easy to rebase all the time, I would ask: why do I want to do that? Now I don't even think about it, I just rebase all the time.

Re: Jujutsu for busy devs

#78

Post by sunshowers »

frizlab wrote: post #74
sunshowers wrote: post #52

Earlier quoted context omitted.

I do mean suspending the rebase and going to do something else, yes. It's a weird thing to do in git , because the conditions that git creates makes it weird. It is completely natural with jj, because jj doesn't have any modal states at all. (This is one of the key reasons jj is both simpler and more powerful than git — no modal states.)

Modal states are actually good IMHO.

I feel like I just outlined a situation where something that's weird in git is completely natural in jj. Maybe I miscommunicated?

Re: Jujutsu for busy devs

#79

Post by bjackman »

stouset wrote: post #64
bjackman wrote: post #45

Earlier quoted context omitted.

Counter point: I adopted it internally at Google (there's a backend for Piper, Google's monorepo Perforce thingy). I don't do my day-to-day work in the monorepo but I still jump in there once or twice a week. I adopted JJ because the existing frontend (Mercurial-based) is slow while JJ is fast. It's nice, I really like it! I'll probably switch to it as my main VCS eventually. But it doesn't feel that important to me.…

I'm not entirely sure that "after using it I really like it and I'll switch eventually" is that much of a counterpoint :) What really kept you from staying with it? It does seem like if your workflow involves a lot of nasty rebases you'd reap dividends from something like jj. I was also someone who'd mastered git (hell, I've written a git implementation) so I get having its patterns deeply ingrained.

Yeah I guess it confirms your point in a way too.

There's nothing keeping me from switching except the activation energy cost. Almost every aspect of working in my area (Linux kernel) is painful so I'm constantly investing in tooling and workflow stuff. So usually I just don't feel like investing EVEN MORE in the area of tooling that's probably least painful of all.

So yeah this is still basically a recommendation for people to try JJ!

Re: Jujutsu for busy devs

#80

Post by 0cf8612b2e1e »

oxidant wrote: post #71
0cf8612b2e1e wrote: post #8

Earlier quoted context omitted.

No that is correct, and also a habit I am trying to break. The reasonable argument is that we should stop running code with untracked state. Either the changes are important and should be committed or not. Otherwise you are recording code versions that never truly existed during development. Where this gets extra sticky for me is tooling which refuses to distinguish repo wide config vs a local only version. VSCode be…

Counterpoint: Why should my println debugging get committed? They're not "important" for the final product but important for development.

The logic is once you are ready to commit you delete all of the debugging stuff. Otherwise you are committing an illusionary state of the repo that only existed by manipulating the stage.

I am a black kettle here as I frequently commit individual lines amongst a sea of changes, but I do appreciate the theoretical stance of jj.

Post reply on HN