[HN Gopher] What I've learned from jj
___________________________________________________________________
What I've learned from jj
Author : eproxus
Score : 71 points
Date : 2025-05-02 08:21 UTC (14 hours ago)
(HTM) web link (zerowidth.com)
(TXT) w3m dump (zerowidth.com)
| account-5 wrote:
| I would really love a comparison between JJ and fossil. I use
| fossil for personal projects instead of git. So I'd like to know
| if I should consider JJ.
| graemep wrote:
| It looks like it is aimed at larger projects, whereas fossil is
| nice for personal projects because it was designed by and for a
| small team.
|
| JJ itself uses Github, where as fossil is very easy to self-
| host including issue tracking, wiki etc.
| 2freedi wrote:
| I began using Jujutsu as my VCS about 2 months ago. Considering
| most of my work is on solo projects, I love the extra flexibility
| and speed of being able to safely fixup recent commits. I also
| love not having to wrangle the index, stashes, and merges.
|
| `lazyjj` [1] makes it easier to navigate around the change log
| (aka commit history) with single keypresses. The only workflow
| it's currently missing for me is `split`.
|
| For the times when I have had to push to a shared git repo, I
| used the same technique mentioned in the article to prevent
| making changes to other developer's commits [2].
|
| It's been a seamless transition for me, and I intend to use
| Jujutsu for years.
|
| [1] https://github.com/Cretezy/lazyjj [2] https://jj-
| vcs.github.io/jj/latest/config/#set-of-immutable-...
| nchmy wrote:
| Check out jjui - it is VASTLY better, and the dev is extremely
| open and responsive to feature requests.
|
| https://github.com/idursun/jjui
| yowlingcat wrote:
| Nice writeup -- had been wondering about how it compares to Git
| (and any killer features) from the perspective of someone who has
| used it for a while. Conflict markers seems like the biggest one
| to me -- rebase workflows between superficially divergent
| branches has always had sharp edges in Git. It's never
| impossible, but it's enough of a pain that I have wondered if
| there's a better way.
| steveklabnik wrote:
| For me, it's not so much that jj has any specific killer
| feature, it's that it has a fewer number of more orthogonal
| primitives. This means I can do more, with less. Simpler, but
| also more powerful, somehow.
|
| In some ways, this means jj has less features than git. For
| example, jj doesn't have an index. But that's not because you
| can't do what the index does for you, the index is just a
| commit, like any other. This means you can bring to bear your
| full set of tools for working on commits to the index, rather
| than it being its own special feature. It also means that
| commands don't need certain "and do this to the index" flags,
| making them simpler overall, while retaining the same power.
| KwanEsq wrote:
| Huh, reading the penultimate ""Units of change" and
| collaboration" section reinforces the feeling that Github PRs
| really are a poor way to do code submission/review, and have been
| holding back a lot of the industry from better ways of working
| for a long time.
| dorian-graph wrote:
| It's maddening, considering their size, and that there are
| proven other examples out there of versioned change sets and
| divorcing the commit ID from the content ID.
| abcd_f wrote:
| A thing to learn from JJ's performance is that not everyone is
| cut out to direct Star Wars movies.
| renerick wrote:
| This article covers my own experience with JJ very accurately.
| I'll even go as far as to say that if had to write my own article
| about jj, I'd use exactly the same talking points and examples.
| Great writeup
| dorian-graph wrote:
| Like the author, I'd appreciate a stacked PRs _approach_ ,
| integrated with GitHub (unfortunately). E.g. `a - b - c - d`
| where I have PRs open for `b`, `c` and not yet on `d`, that are
| "linked" to the jj changes. So 1 change per PR or it could even
| be multiple. I've lately become a huge fan of git-spice, that
| _just works_.
| IshKebab wrote:
| Stacked PRs is clearly a nice workflow... _except_ that forges
| like Github generally have really poor support for them.
|
| I wish Github would just allow you to say "this PR depends on
| this other PR", and then it wouldn't show commits from the
| other PR when reviewing the stacked PR.
|
| But as far as I know you can't do that.
| xrd wrote:
| If you change the target branch it will only show commits
| that are against that. I wish GitHub did that automatically
| because it has the parent commit tree but when do you that
| you'll only see commits that diverge from the target
| branch/pr.
|
| Is that what you want?
| aaomidi wrote:
| That works but depending on how you merge the PR, you end
| up needing to do a rebase on all of your future PRs.
|
| I really wish 1PR = 1 commit with revision based diffs.
| Similar to gerrit.
| IshKebab wrote:
| Not really. I've tried that with Gitlab, but it's kind of
| awkward. My PR _isn 't_ to merge branch B into branch A.
| For instance if the project owners see the PR for B and say
| "yeah great! I'll merge this" and press merge, it will just
| merge it into branch A and then close your PR!
|
| It's a hacky workaround at best. I want _proper_ support. I
| want Github to disable the merge button until the
| dependencies are merged. I want it to actually list the
| dependencies and link to them. I want the target branch to
| be `main`.
|
| I think if they did those 3 things it would go 90% of the
| way. Too much to ask though clearly.
| dorian-graph wrote:
| Another person has commented that you can do this, but it's a
| little known thing. git-spice automatically manages it for
| you too.
| steveklabnik wrote:
| It also doesn't work from forks.
| dorian-graph wrote:
| This has annoyed me a few times, just recently a week
| ago. Thanks GitHub.
| k__ wrote:
| I often have "no changes" in my Codespaces, because I haven't
| committed then yet.
|
| Would be nice, if Codespaces keeps the JJ change stored
| somewhere, so it isn't tied to the lifetime of the machine.
| jffhn wrote:
| Jujutsu - I like the name.
|
| I often see programming as going MMA with data, until you get
| what you want out of it.
|
| Using brute force algorithms is going berserk, vibe coding is
| spamming summons in hope they get the job done, etc.
| az09mugen wrote:
| Agreed, I'd just like to complement vibe coding feels like
| spamming _retarded Mr Meeseeks_ hoping they get get the job
| done. It 's _probabilistic programming_
| cadamsdotcom wrote:
| It's clear from multiple posts over years that jj has a better UX
| than plain git.
|
| Why not just merge it into git?
___________________________________________________________________
(page generated 2025-05-02 23:00 UTC)