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

31–40 of 552 posts

Re: Jujutsu for busy devs

#31

Post by dcre »

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

Re: Jujutsu for busy devs

#32

Post by stouset »

bravesoul2 wrote: post #25
sunshowers wrote: post #23

Earlier quoted context omitted.

Note that jj is not a frontend for git or an abstraction layer over git — rather, the git object store format is one of at least two backends to jj.

Thanks. That would make me interested in it for a personal project where I only use jj.

There's really no cost to trying it out on an existing project with other people. It natively interoperates with git. Nobody needs to know you're using something different, and you can always fall back to using git commands if you need to do something you haven't learned yet.

Re: Jujutsu for busy devs

#33

Post by stouset »

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 of inertia. Of course both of these do happen—nothing is perfect—but they are by far the exception. From my own personal anecadata, I have seen a 100% conversion rate from everyone who gave it a serious try.

I encourage you to let today be the day that you decide to try it out. It is far less effort to make the switch than you probably think it is: I was productive the same day I switched and within a week I had no remaining situations where I needed to fall back to git commands. You will quickly be more productive and you will find yourself amazed at how you ever got by without it.

Re: Jujutsu for busy devs

#34

Post by dcre »

matthewkmayer wrote: post #28
Svoka wrote: post #24

I want to be excited about Jujutsu, but what always bothers me about JJ is that if you search the page you can find 'jj' 47 times and 'git' - 49. Is there a good explanation of Jujutsu without referring to git? May be with some pictures? Am I the only one bad with memorizing SHAs when reading? Also, does it work with other people? Would it work in repo with 5 contributors? 20? 500? EDIT: I am looking for tutorials wi…

Try https://senekor.github.io/jj-for-everyone/introduction.html . A snippet from the intro: "At the time of writing, most Jujutsu tutorials are targeted at experienced Git users, teaching them how to transfer their existing Git skills over to Jujutsu. This blog post is my attempt to fill the void of beginner learning material for Jujutsu."

That’s very fun. I’ve been wondering what would happen if someone new to programming started with jj directly.

Re: Jujutsu for busy devs

#35

Post by packetlost »

stouset wrote: post #22
krackers wrote: post #16

Earlier quoted context omitted.

>you have to manually rebase every subsequent change What do you mean by this? You can do an interactive rebase in git as well. The real issue is non-trivial merge conflicts which is going to be an issue no matter you use.

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 in a meaningful way.

Re: Jujutsu for busy devs

#36

Post by steveklabnik »

arp242 wrote: post #27
sunshowers wrote: post #20

Earlier quoted context omitted.

I think jj just uses the 4 bit (16 color) terminal palette, so if a color is unreadable, you can update your terminal theme accordingly.

Some programs set the background colour and some don't. For example pamix sets the background to black, or tmux's statusline, or ngrok. It's not really possible to define one terminal scheme that always works.

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

Re: Jujutsu for busy devs

#37

Post by packetlost »

sunshowers wrote: post #19
krackers wrote: post #16

Earlier quoted context omitted.

>you have to manually rebase every subsequent change What do you mean by this? You can do an interactive rebase in git as well. The real issue is non-trivial merge conflicts which is going to be an issue no matter you use.

git rebase -i is a much worse experience than jj's autorebasing of descendants. For example, with git rebase -i you can't decide to do something else in the middle of the rebase — you're in that state until the rebase is completed or abandoned. Merge conflicts are also significantly better with jj because they don't interrupt the rest of your flow. And most importantly, the two features work together to create someth…

> 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 a weird thing to do.

Re: Jujutsu for busy devs

#38

Post by notmywalrus »

ethan_smith wrote: post #17
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…

[flagged]

...no? On all counts.

`jj ignore` is not a command. [1]

There is no such thing as `.jjignore` files [2], [3].

`--no-snapshot` is not a flag, neither on `jj edit` nor in general. Additionally, it doesn't make sense conceptually --- `jj edit` changes the working copy, which will then propagate changes to the selected commit every time you edit a file.

If you want to check out an old commit without amending it, you `jj new` on top of it. If you end up making changes that you don't care about, you can `jj abandon` them.

[1]: https://jj-vcs.github.io/jj/latest/cli-reference/

[2]: https://github.com/jj-vcs/jj/issues/3525

[3]: https://jj-vcs.github.io/jj/latest/working-copy/#ignored-fil...

Re: Jujutsu for busy devs

#40

Post by what »

bravesoul2 wrote: post #21
arp242 wrote: post #15

Earlier quoted context omitted.

I don't especially like git. I stuck with mercurial for a long time. But that was ten years ago. Now git is kind of hard-wired in my brain. By and large, it works well enough. It's not really clear to me that Jujutsu offers a significant enough of a benefit to spend the time re-wiring my brain, never mind dealing with the initial setup (e.g. the unreadable colours, setting up some scripts/aliases for things I like).

Yeah I find abstraction layers suck a bit. Same with miso and uv (for python). They don't "just work TM" and now I have 2 problems. By just work I couldn't install miso onto a fresh Ubuntu without 404 errors and uv kept bitching about my pyproject file instead of just working or trying to fix it. Some of these tools do just work. E.g. nvm seems to just work and is much nicer than raw node installs.

What is miso?
Post reply on HN