Earlier quoted context omitted.
Just like you can run `git add -p`
yes but no
Explain the difference.
jj – the CLI for Jujutsu
241–250 of 517 posts
Re: jj – the CLI for Jujutsu
#242I really wanted to like JJ, it was handy for a few months when I used it. But for me in the end I reverted back to regular git. What triggered me to go back was I never got a really clean mental model for how to keep ontop of Github PRs, bring in changes from origin/main, and ended up really badly mangling a feature branch that multiple contributors were working on when we did want to pull it in. I'll probably try it…
locally? sure. stacked changes in jj are great. but the moment you push to GitHub, the review UI still thinks in SHAs. a lot of the pain just moves from the author to the reviewer.
Re: jj – the CLI for Jujutsu
#243Here are some notes on Jujutsu from Evan Martin that I found interesting/useful:
https://neugierig.org/software/blog/2025/08/jj-bookmarks.htm...
Re: jj – the CLI for Jujutsu
#244Earlier quoted context omitted.
does trivially working on 3 PRs in a single checkout and pushing focused changes to each one independently without thinking twice count? if you don't need this, you might not see any value in jj and that's ok. you might use magit to get the same workflow (maybe? haven't used magit personally) and that's also ok.
Actually it is a anti-demo, because while software allows you to do it, I don't think many software engineers can work on this.
in large enough monorepos and teams and big enough changes you either do it like this or have a humongous giga-PR which eventually starts conflicting with everything.
Re: jj – the CLI for Jujutsu
#245Anything new or special in jj that allows me to work with large binary files simply? To me, this is still unsolved in terms of providing an elegant solution (e.g. things like Git Large File Storage (Git LFS) are awkward).
I've heard that jj has support for non-git backends?
Can anyone comment on how difficult it would be to add support for another backend, any docs or examples?
I have a project[0] that does the large file thing well, but is missing most of the version control porcelain. I've been looking for the path of least resistance to integrate it into something with a larger user base.
Re: jj – the CLI for Jujutsu
#246Earlier quoted context omitted.
Yes, but it's a sad state of affairs that the official jj docs point to your tutorial, which is incomplete (and IIRC, more incomplete than in the past - I think you took down some topics).
Nope, I haven't taken anything down. I have merged in some contributions from others though, it's actually grown (Manish, iirc, contributed the Gerrit section).
Oh, OK. Must be a bad memory. I often go to your tutorial looking for something I could have sworn I read over a year ago and not find it. I must have read it elsewhere.
Re: jj – the CLI for Jujutsu
#247Hey folks! So, I haven't updated the tutorial in a long time. My intent is to upstream it, but I've been very very busy at the startup I'm at, ersc.io, and haven't had the chance. I'm still using jj every day, and loving it. Happy to answer any questions!
jj automatically hides "uninteresting" changes. Most of the time, this is good.
Occasionally, I need to see more changes. It is not obvious to me how I get jj to show me elided changes. I mean, sure, I can explicitly ask jj to show me the one ancestor of the last visible change, and then show me the ancestor of that one, etc. Is some flag to say: "just show me 15 more changes that you would otherwise elide"?
Re: jj – the CLI for Jujutsu
#248"It's more powerful and easier" is a great claim, but I need examples in this opening page to convince me of the pain I could save myself or the awesome things I'm living without.
A couple things off the top of my head: - You aren't forced to resolve rebase/merge conflicts immediately. You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later. - Manipulating commits is super easy (especially with jjui). I reor…
[dead]
Re: jj – the CLI for Jujutsu
#249"It's more powerful and easier" is a great claim, but I need examples in this opening page to convince me of the pain I could save myself or the awesome things I'm living without.
A couple things off the top of my head: - You aren't forced to resolve rebase/merge conflicts immediately. You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later. - Manipulating commits is super easy (especially with jjui). I reor…
I also like the powerful revision querying mechanisms that they pulled in from mercurial. They seem to work just like mercurial revset queries which can be used in various operations on sets of revisions.
I would like them to have mercurial's awesome hg fa --deleted when it comes to history trawling, but apparently for it to work well, they also need to swap out git's diff format for mercurial's smarter one, so I'll be waiting on that for a while I suppose.
Re: jj – the CLI for Jujutsu
#250Earlier quoted context omitted.
does trivially working on 3 PRs in a single checkout and pushing focused changes to each one independently without thinking twice count? if you don't need this, you might not see any value in jj and that's ok. you might use magit to get the same workflow (maybe? haven't used magit personally) and that's also ok.
Can you show how you would do this in jj? I know how I would do this in git, but don't really see how this would be in jj. I currently don't use it in my workflow, but if it is super easy in jj then I could see myself switching.
This is how I'd do it:
jj new branch1 branch2 branch3
When you want to move specific changes to an existing commit, let's say a commit with an ID that starts with `zyx` (all jj commands highlights the starting characters that make the commit / change unambiguous):
jj squash -i --to zyx
If you want to move changes to a new commit on one of the branches:
jj split -i -A branch1
There's one thing that's a bit annoying, the commit is there but the head of the branch hasn't been moved, you have to move it manually (I used + to get the child to be clearer, but I usually just type the first characters of the new change id):
jj bookmark move branch1 --to branch1+