Live data from Hacker News

jj – the CLI for Jujutsu

steveklabnik.github.io

331–340 of 517 posts

Re: jj – the CLI for Jujutsu

#331
post #252

I was already pretty happy with svn to be honest, I dont see myself switching away from the industry standard today for no substantial reason. in my opinion git was only able to change the standard thanks to github and a popular author (i love git and its branching, but I dont think it would have been enough if it was just for that). I personally believe its going to be very difficult for jj to replicate that.

In my opinion, svn lost to git because git is just so much better in a distributed environment. To me the improvement between git and svn is much more than the improvement between svn and cvs. In fact, by many aspects, I preferred cvs, but now that we have git, they can both go to hell.

Now, it is not the only DVCS, there is also Mercurial, which is built on similar principles. It could have become the standard, but I agree with you that the reason it didn't probably has to do with Github and Linux.

jj isn't fundamentally different from git, it is actually compatible with git, which is a good and a bad thing. Good because it makes transition easy, bad because it is fundamentally the same thing and there is no pressing reason to change.

But jj definitely look nicer than git, which is not hard, under the hood, git is great, but it is ugly. It started off as a hack and it still shows. I think the common sentiment of "I know git, I don't want to learn a new VCS" mostly tells about how painful the process of learning git was. If you had started off with Mercurial, like I did, I am sure it would feel much smoother, it is just git that is messy. For jj, it looks like they took the best parts of git and mercurial, so hopefully, the transition will be rather painless.

Re: jj – the CLI for Jujutsu

#332
post #310
post #30

Earlier quoted context omitted.

This is exactly how someone explained Git to me 12 years ago or so, and I’ve finally wrapped my head around it. Not changing now.

If I'm understanding the thread correctly, I have a git alias to `git commit --amend --no-edit`, for exactly this workflow. When I'm hacking on something locally and want to just keep amending a commit. I only ever do this if it's HEAD though.

Yes, one way to think about jj in a sort of low-level way is that every jj command does the equivalent of that, every time.

(You can also set up watchman and have that happen on every file change...)

Re: jj – the CLI for Jujutsu

#333
post #294

Earlier quoted context omitted.

That's my overall point: the argument itself (with respect to the current state of the repo) is what determines the behavior. I don't think this is anywhere close to as intuitive as commands that only ever accept one "type" of argument (and erroring if it's different).

I stand corrected by this one scenario, but I’ve been using git for over a decade and never found that useful. Just don’t use checkout on a file path, there is no need.

I find this kind of advice to be a more scathing indictment of an interface than a critic could ever muster: asking users to forego available functionality so that some sense of order can be imposed.

Re: jj – the CLI for Jujutsu

#334
post #222

Earlier quoted context omitted.

Right, but that’s different from working in a team environment where everyone else continues using git.

fwiw I don't use it personally but some people on my team use it while the others use git, and nobody complains.

Yeah same here, have been using jj exclusively, the only reason people notice is because my branch names default to the changeid in my setup so I've had questions about the random looking strings.

Re: jj – the CLI for Jujutsu

#335

jj has made me much more comfortable using non-linear DAGs in my trunk-based development workflow. Several changes with the same parent, changes with several different parents, etc. I used to have a habit of imposing an unnecessary ordering structure on my work product. My stack of changes would look like A -> B -> C -> D, even if the order of B and C was logically interchangeable. jj makes DAGs easier to work with b…

Do you use a mega-merge + absorb workflow on top of the faned-out changes?

Re: jj – the CLI for Jujutsu

#336
post #135

Earlier quoted context omitted.

I believe the full docs page does indicate that there are binaries to install via popular package managers [1] [1]: https://docs.jj-vcs.dev/latest/install-and-setup/

I did check that page, as far as I can tell you still need to run Cargo which I don't want to do because I don't care about Rust. I'm not complaining for the sake of complaining, I'm saying if they want to play in the Big Boy leagues, they need to do things right.

You do need Cargo to build from source.

If you're on Arch, gentoo, or openSUSE, you can use the package. It is true that Debian has not packaged jj yet.

It'll get there, and it's fine if you'd rather wait until things are more mature.

Re: jj – the CLI for Jujutsu

#337
post #48

Is there a concise introduction / overview of jj? I've read 8 pages of this link and the author is still in preambles and considerations... Not my favourite style of article!

I can be a bit verbose, it's true :)

You've got some decent replies, but if you give me some background, like how comfortable you are with git, how much you care about certain details, I'd be happy to respond here with something more concise.

Re: jj – the CLI for Jujutsu

#338
post #315

Earlier quoted context omitted.

Unless you use LFS, submodules, or hooks at your org.

Submodules work fine but yeah, it's frustrating that lfs is taking so long. But there seems to be some momentum recently https://github.com/jj-vcs/jj/pull/9068

The git compatibility page states that submodules are not supported

https://docs.jj-vcs.dev/latest/git-compatibility/

Re: jj – the CLI for Jujutsu

#339

For those who switched, what is the main selling point that made you stay with Jujutsu?

For me, can do anything complex in terms of history rewriting without ever shooting myself in the foot (worse case just `jj undo`).

And the UI is pretty intuitive so don't really have to search for a solution, usually the command to use is obvious (tho I guess now you could delegate the UI to an LLM to ask it to give you the right incantations).

Re: jj – the CLI for Jujutsu

#340

Earlier quoted context omitted.

For me, it wasn't so much that jj enabled things I couldn't do before, though there are some things. What it enabled was me doing the things I was doing, but in a more easy way. This also leads you to do things that you can do, but sometimes avoid because it's a lot of work.

I guess that makes sense but also reinforces the confusion I have on whether jj is just another git "porcelain" (aka UI), or a replacement for git altogether. If it aims to mainly improve the UX (do the same things you were doing before but easier), then it's irrelevant to those of us who have been lucky to find and learn sensible UXs. If it aims to be a git replacement, I'm a little curious why the developers would…

> then it's irrelevant to those of us who have been lucky to find and learn sensible UXs

Only if you're a solo dev that doesn't work on a team or have to mentor new devs that haven't developed good intuitions for this.

This strikes me a lot like the C vs. safer programming language debate all over again.

Post reply on HN