Live data from Hacker News

The creator of Jujutsu has joined ERSC

ersc.io

281–282 of 282 posts

Re: The creator of Jujutsu has joined ERSC

#281

Earlier quoted context omitted.

I love the index, and often have "uncommitted" stuff lying around. jj makes doing this easier because you represent the index as an unnamed commit, and everything just works, as opposed to needing to manage the index vs committed changes with separate tools.

The absence of "needing to manage the index" is what breaks my workflow.

What I mean is, you manage the index with the same commands that you manage commits with. The emphasis is on "with separate tools" not "manage the index".

I am super curious as to what you mean specifically, but I also know that getting into details can be annoying, so if you have some specifics I'd love to hear more about them. I loved git's index so this isn't coming from a place of "the index sucks and you shouldn't care about it" it's "I think jj executes the index better than git does actually". But also if you don't, that's fine by me too, if you like a tool you should continue to use it.

(I never set autosquash either)

Re: The creator of Jujutsu has joined ERSC

#282
post #185
post #143

Earlier quoted context omitted.

I was a skeptic until a few months ago. It’s my daily driver now. I’ve got sizable amount of people committing to the same repo, many are not skilled with git. So I deal with weird crazy “how did you ever get the repo into this state” issues not infrequently. JJ is just so low friction. The seamless and painless shuffling of commits, working up and down the commit chain without explicit rebasing, unchanging change-id…

They're not experienced with git, but still use the command-line? Interesting. Or would you think a jj GUI would help them?

CLI is preferred from my point of view if only because it's the supported standard interface. VSCode's version control interface is reasonably close to a standard, and I love the tree view there. But generally I don't want to use random third party things because they either aren't consistent (i.e. now I have to learn what joe schmoe thinks a version control interface should be), or don't stick around long enough.

But I don't tell my team what they have to use as long as it's compatible. The last thing I want to do is try to teach them a different VCS when they've spent time learning how to get by with git.

I've told them about JJ, what I like, what pain points it solves for me. They are all adults, they can make their own decisions about it.

JJ is for me. It helps me unwind some rather elaborate problems we've had with rebasing, or dealing with conflicts from bringing some old support branch up to date, or back porting some particular thing. It helps me create pretty clean MRs, break things up into smaller reviewable chunks, etc. You can do all this with git, but it's easier in JJ. In particular if you have to do shuffling and rebasing and conflict arise. JJ lets you solve conflicts asynchronously to rebasing. Git stops you in your tracks. There's some rerere thing that is supposed to help but give me a break. Git's a train wreck of dumpster fires. But it's still been basically better than everything else since svn.

Until JJ IMHO. Valid arguments can be made for other things like maybe mercurial or even fossil. But JJ is the most pain-free vcs evolution I've seen.

Mercurial's big failing was making too many critical things optional. It's the same screw-up riscv is going through now in the chip architecture space.

Post reply on HN