[flagged]
The tower continues to build higher and higher, I wonder when it will collapse under its own weight
jj – the CLI for Jujutsu
51–60 of 517 posts
Re: jj – the CLI for Jujutsu
#52Earlier quoted context omitted.
You don't replace. jj is backed by git anyway.
You can switch an existing git repo to jj by using: jj git init --git-repo my-repo I think (but CANNOT PROMISE) that just removing the .jj folder will bring you back, but definitely take a backup of .git before you try this in case I’m wrong.
No that is correct when in colocate mode (which is the default mode). Simply removing the .jj folder will "de-jj" the repo entirely, but will leave you in a headless state. Simple to fix with a `git switch` though.
If you are _not_ in colocate mode, the .git folder is located _inside_ the .jj folder. So worth checking!
Re: jj – the CLI for Jujutsu
#53Is it better for AIs? That’s the only reason I would care.
The cli and a few concepts have evolved with time past the model's knowledge cutoff dates, so you have to steer things a bit with skills and telling it to use --help a bit more regularly.
I find it reasonably good with lots of tweaking over time. (With any agent - ask it to do a retrospective on the tool use and find ways to avoid pain points when you hit problems and add that to your skill/local agents.md).
I expect git has a lot more historical information about how to fix random problems with source control errors. JJ is better at the actual tasks, but the models don't have as much in their training data.
Re: jj – the CLI for Jujutsu
#54Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow.
I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state.
Since it's git compatible, it feels like it must work to add files and keep files uncommitted, but just by reading this tutorial I'm unsure.
Re: jj – the CLI for Jujutsu
#55I love jj, but mostly I use jjui. I would like more uniformity in the way jjui handles commands when you are viewing changes vs when you are viewing files within a single change. Often I just make my changes and leave it there without `new`, as I am not sure which file should go in a single commit. I just leave it there and I interactively commit later. For me to use `new` more, I would like the ability to also simpl…
In jjui, you can select multiple changes to squash/rebase by pressing space bar before pressing S or r. Is that what you mean?
Re: jj – the CLI for Jujutsu
#56Earlier quoted context omitted.
A bit of both. I guess it's nice, but nothing I actually care about.
I had a similar thought: there surely are lots of young folks who will be all excited with this (I was back in the CVS/SVN days when git appeared). But nowadays I'm extremely lazy to attempt to learn this new thing. Git works, I kind of know it and I understand its flow.
Same here, I’m not experiencing so much friction to justify looking for an alternative
Re: jj – the CLI for Jujutsu
#57Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state. Since it's git compatib…
It doesn't need you to think that way at all.
`jj new` simply means "create a new commit [ontop of ]" - you don't have to describe it immediately. I never do.
I know that the intention was to do that, and I tried forcing the habit, but I too found it counter-productive to invariably end up re-writing the description.
Re: jj – the CLI for Jujutsu
#58Is 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 wrote a brief intro to Jujutsu here: https://mkaz.blog/code/jujutsu-vcs
Re: jj – the CLI for Jujutsu
#59Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state. Since it's git compatib…
My preferred workflow is to start with a new change, pick the changes I want, then use jj commit to describe the change and create a new empty one on top. Feels very similar to my old git workflow.
If I end up with multiple features or abstractions in one change (equivalent to the “dirty repo”), jj split works very well as an alternative to the git add/git commit/repeat workflow tidying up one’s working copy.
Re: jj – the CLI for Jujutsu
#60Has anyone found a good code review workflow with `jj`? My problem is that GitHub doesn't remember the content of the last reviewed SHA, so every time I push a new change from jj, reviewers lose the delta from their last reviewed commit. To work around this I stopped moving revs (squash/rebase) after review starts, which creates awkward local graphs if I have to merge from main for merge conflicts. Graphite works but…
The last reviewed sha is generally available on the PR page (not the changes page) when you force push. There should be a changes since review link somewhere near the push. When reviewing, you can also mark individual files as reviewed (useful in larger reviews where you're incrementally reviewing files). If you do this, only files that are changed will be expanded when you come back to the review.
yeah, this is where my complaint is - github shows a "compare" button when I force push, but it's not linked to the PR review. The "file changed" status is often not granular enough - if I change one line, force push, the entire file gets marked as unreviewed. the github "changes since your last review" is commit-based, not sha-based.
what I want is something like graphite/gerritt/google's critique where after each force push, the review page shows only the true delta between the two shas (similar to the "compare" button in github, bu as a reviewable unit).
poked around on github, doesn't look like the stacked PR feature has affected this "changes since your last review" selector yet :(