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

111–120 of 552 posts

Re: Jujutsu for busy devs

#111

Post by tcoff91 »

do_not_redeem wrote: post #55
accelbred wrote: post #39

Is there a magit equivalent? I heavily use magit's interactive features and extensions to the git UI (like spinoff, absorb, or the auto-backup thing)

jjui is the best VCS TUI I've ever used. It's even smoother than magit, but I think most of that is because of jj itself. Spinoff and absorb are both native jj features (jj rebase and jj absorb, respectively) https://github.com/idursun/jjui

I’ve got to check this out.

I’ve really been loving these two neovim JJ plugins

For splitting commits: https://github.com/julienvincent/hunk.nvim

For resolving conflicts: https://github.com/rafikdraoui/jj-diffconflicts

Re: Jujutsu for busy devs

#112

Post by esperent »

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…

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

Re: Jujutsu for busy devs

#113

Post by idoubtit »

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

I think that comparison is unclear and unfair. The core is that instead of:

    jj rebase -r @ -B abc
the recommended Git alternative is:

    git rebase -i abcd1234
    # move the last line to the desired position
This is a process I use heavily, and one of the rare cases where I prefer the Git way: less cognitive load (I don't need to memorise options b/s/r/d/A/B for `jj rebase`) and the interactive editing of the history feels simpler (especially if I move several commits).

I've used jj for a few weeks, but switched back to git. I'm fluent enough with Git so I never struggle any more. jj mostly felt nice, but the added value was not enough to replace years of expertise.

Re: Jujutsu for busy devs

#114

Post by globular-toast »

0x457 wrote: post #44
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…

Reason I like git is because I use like 2% of its features. I don't fall for propaganda that I need to use bisect and co. 99% of git commands I call are aliased to 3 characters, so it's dense terminology doesn't bother me.

I relish the day I get to use bisect. It's like, finally I get to use all this version data I've been collecting.

I don't understand why anyone would say you have to use it. It does a very specific thing, namely finding the source of a regression between two commits. If you need it you'll know.

Re: Jujutsu for busy devs

#115

Post by Disposal8433 »

esafak wrote: post #61
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…

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.

Re: Jujutsu for busy devs

#116

Post by tcoff91 »

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.

First class conflicts are way better than modal states.

https://ofcr.se/jujutsu-merge-workflow/

I literally will have like 4 PRs in flight at once and have an octopus merge of all my separate PRs that I can then work on top of. JJ can rebase all 4 separate branches, the octopus merge, and the work on top of the octopus merge in a single command: jj rebase -d main.

If there are conflicts I can then resolve them whenever I want.

You have no idea what you are talking about if you think git’s interactive rebase holds a candle to what jj rebase can do.

Re: Jujutsu for busy devs

#118

Post by deredede »

stouset wrote: post #11
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.

It’s not just that it’s simpler, it’s that the primitives and interaction model are also strictly more powerful. A ton of extremely useful workflows that are an utter pain in the ass with git are absolutely trivial with jj. One example is a series of dependent PRs. This is excruciating in git if you ever need to make a fix to an earlier PR because you have to manually rebase every subsequent change. It’s trivial in j…

> This is excruciating in git if you ever need to make a fix to an earlier PR because you have to manually rebase every subsequent change.

Spreading the word about `git rebase --update-refs` that will automatically update any branches that point to commits along the path (very useful with stacked branches). It is less convenient than what jujutsu offers (you need to know the branches to update, where jujutsu automatically updates any dependency), but still a very useful if you don't want to or can't switch to another tool.

Re: Jujutsu for busy devs

#120

Post by deredede »

packetlost wrote: post #51
plandis wrote: post #43

Earlier quoted context omitted.

As far as I know, by default Git doesn’t enable the “reuse recorded resolution” feature so if you made a change to the first commit you’d have to manually do the same thing for any subsequent commits.

If you have 5 different branches, sure. Again, the reason you create a bunch of branches for separate review is because that's what the "git forge" abstraction generally expects. It's not actually how code reviews are done by the people who wrote it. You can also just enable that feature (rerere).

> It's not actually how code reviews are done by the people who wrote it.

What do you mean by that? Even if you do review by emailing patchsets those are still managed locally using branches, to my knowledge.

Post reply on HN