Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I see a future in jj

steveklabnik.com

Post reply on HN
Print view View original

291–300 of 336 posts

Re: I see a future in jj

#291

Post by steveklabnik »

nonethewiser wrote: post #281
1718627440 wrote: post #60

Earlier quoted context omitted.

I think they mean what other branch some branch was originally branched off from.

Yes. I could see confusion about the term "parent" but get? IDK what the confusion is there.

It was just like, in what context? To print a log? To rebase something? "get" is not a command exactly. That's it.

Some of it is also what a "branch" means to different people can mean different things: https://jvns.ca/blog/2023/11/23/branches-intuition-reality/

But yeah, as others have said, not really possible in a general way, sadly.

Re: I see a future in jj

#292

Post by lowboy »

nonethewiser wrote: post #281
1718627440 wrote: post #60

Earlier quoted context omitted.

I think they mean what other branch some branch was originally branched off from.

Yes. I could see confusion about the term "parent" but get? IDK what the confusion is there.

If you're looking to model git branches as much as possible with jj bookmarks and assume that:

- the working copy has a bookmark pointing to it

- there's some ancestor with a bookmark

- there's a single linear path between the two with no other bookmarks in between

Here's an example that represents a branch containing 3 commits named "bookmark-05ff" branched off of "bookmark-6825".

    > jj log -r y:: -T builtin_log_redacted
    @  urplyywu user-482a 2025-10-23 13:24:52 bookmark-05ff a334e2e1
    │  (empty) (redacted)
    ○  lxxtnlxw user-482a 2025-10-23 13:24:46 git_head() 7e32fa6b
    │  (empty) (redacted)
    ○  omktyuos user-482a 2025-10-23 13:24:13 7668b0bb
    │  (empty) (redacted)
    ○  ykzktoux user-7b7f 2025-10-23 13:23:47 bookmark-6825 98bfcbde
    │  (empty) (redacted)
    ~
In this case, the following log would get you the commit pointed to by "bookmark-6825":

    > jj log -r 'latest(ancestors(@) & bookmarks(), 2) ~ @' -T builtin_log_redacted
    ○  ykzktoux user-7b7f 2025-10-23 13:23:47 bookmark-6825 98bfcbde
    │  (empty) (redacted)
    ~
I'm using the builtin_log_redacted output template. Normally you'd have actual bookmark names, descriptions, user, etc.

Also note this bakes in a lot of assumptions and is brittle. As many others have said, it’s not generalizable.

Re: I see a future in jj

#293

Post by steveklabnik »

cryptonector wrote: post #289
steveklabnik wrote: post #266

Earlier quoted context omitted.

I’m curious to hear more about what you find opinionated, I think one struggle I’ve had teaching jj to people is that it’s extremely flexible.

I'll have to look again. Last I looked at it I felt like jj was a straightjacket.

It's all good. If you do give it a try and feel like letting me know how it goes, I'm genuinely interested. No worries if not :)

Re: I see a future in jj

#294

Post by steveklabnik »

pm215 wrote: post #287
jpgrayson wrote: post #284

Earlier quoted context omitted.

StGit maintainer here. I have been a jj user for over a year now. It has proven superior to StGit for all of my workloads. I even use jj when maintaining StGit. An incomplete list of wins vs StGit includes: - jj makes managing multiple branches fluid, whereas stg has limited tools for managing patches between stacks. 'stg pick' is largely all there is. It's a real dance to move a patch between stacks. - jj has a much…

On that first point, there's a use case I sometimes have where stgit feels very clunky: * I have a branch foo with a stack of patches which are the thing I'm working on, based on a master branch * I have a separate stack of patches on a branch bar (let's say this is a feature that interacts with foo but it's not ready to upstream yet or maybe at all) * I want to test and work on the combination of foo and bar and mak…

jj does do better here: its called the "mega merge" https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim...

Combined with jj absorb, some people just work this way all the time, even.

> I like having a straightforward stack of patches that I can push, pop and reorder and list.

You can work this way too, what you'd want is `jj rebase` with -A, -B, and -r: r for the revision, and A and B for the before and after you want to move it too. This lets you reorder things however you want pretty straightforwardly. I tend to work in a stack of patches too, or at least, way more than I used to.

Re: I see a future in jj

#295

Post by jrockway »

jjmarr wrote: post #151
jrockway wrote: post #109

Earlier quoted context omitted.

Yeah, I always force push. I always treat PRs as one atomic unit ("squash and merge") and the history that goes into the PR isn't relevant to me after it's merged. Maybe once or twice I've regretted this (maybe you want to backport one part of this PR to the release branch, and now you have to manually create that) but in general, how something is made can be ugly and it feels good to me to erase it when something is…

I'm banned from force-pushing at work so this makes jujutsu a challenge for me. The workflow still functions, it just requires me to manually update bookmarks.

I see. I guess you guys keep merging in your upstream branch until it's finally time to merge a PR into that branch? A lot of people like that workflow but it never really made sense to me.

I personally feel like your employer's policy is unusual for PR branches. Other people force pushing? Bad. Force-pushing to `main`? Bad. But force pushing to your own branch when you can delete it and re-create it? Just a waste of your time for no real reason. I wonder what the justification is.

Re: I see a future in jj

#296

Post by klardotsh »

nonethewiser wrote: post #282
klardotsh wrote: post #22

Earlier quoted context omitted.

What a terrible world we're barrelling towards when "LLMs don't know about it" is considered a blocker towards something taking off. Read a blog post, read a man page (which GP says was indeed their solution), or just play with the dang tool, I assure you these things are still possible without the assistance of a predictive text engine helping you!

Should I learn this thing or wait 4 months until the next LLM refresh might have ingested it?

This feels like the same question as in consumer goods: "do I buy this thing now, or do I wait for the potential refresh in 6mo to see if it's better?"

Just get the thing you need now, there's no promise the grass is getting any greener, nor that you're any better off waiting. Maybe the LLM won't learn for 6 months. Or 12 months. Or maybe the AI company will run out of money, or jack up their prices to where you're not using it anymore, or whatever.

Re: I see a future in jj

#297

Post by codethief »

steveklabnik wrote: post #62
weinzierl wrote: post #51

I think the real news is that some people have started to build what might become something like a "jjhub" . https://ersc.io/

I think 'jjhub' is a decent immediate first approximation, and is often how I've started out talking about it with people. At the same time, we have to offer real value here, as you can already use jj with github (and I have for a long time now), so there's more to it than that. But yes :)

> we have to offer real value here

If I may make a suggestion here: Allowing PRs to be stacked, i.e. allowing commits to be reviewed individually, like in Sapling, would be FANTASTIC.

EDIT: See also the link in this comment: https://news.ycombinator.com/item?id=45675335

Re: I see a future in jj

#298

Post by steveklabnik »

codethief wrote: post #297
steveklabnik wrote: post #62

Earlier quoted context omitted.

I think 'jjhub' is a decent immediate first approximation, and is often how I've started out talking about it with people. At the same time, we have to offer real value here, as you can already use jj with github (and I have for a long time now), so there's more to it than that. But yes :)

> we have to offer real value here If I may make a suggestion here: Allowing PRs to be stacked, i.e. allowing commits to be reviewed individually, like in Sapling, would be FANTASTIC. EDIT: See also the link in this comment: https://news.ycombinator.com/item?id=45675335

This is something that I am comfortable saying is absolutely going to be the case.

Re: I see a future in jj

#299

Post by 1718627440 »

SAI_Peregrinus wrote: post #273
1718627440 wrote: post #216

Earlier quoted context omitted.

How does JJ ensure that there are now change ID conflicts on push, i.e. so that no two repos generate the same change-id?

The same way Git ensures that no two repos generate the same commit ID: by using a cryptographic hash function.

What does JJ hash here, when I can modify the whole commit, but the change id stays constant?

Re: I see a future in jj

#300

Post by 1718627440 »

pm215 wrote: post #257
1718627440 wrote: post #227

Earlier quoted context omitted.

But that is the thing, it is not exposed as an implementation detail, it is a skipable part of the user model.

I find myself from time to time with stuff in the index (merge conflicts in particular I think can result in this). I never put anything there explicitly. I would love to be able to configure git such that the index didn't exist, but I can't.

The transparent thing would be to put everything into the index, and configure all the commands to autoupdate the index. This is what happens with the merge conflict, because there is no benefit having resolved merge conflicts not already in the index. So the merge conflicts already do what you want, the other commands need to be modified.
Post reply on HN