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

jj – the CLI for Jujutsu

steveklabnik.github.io

Post reply on HN
Print view View original

21–30 of 517 posts

Re: jj – the CLI for Jujutsu

#21

Post by shuyang »

Has 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 it's $$$, and phabricator/reviewable/gerritt all have significant onboarding hurdles.

Re: jj – the CLI for Jujutsu

#23

Post by roblabla »

shuyang wrote: post #21

Has 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…

I wonder if the recent github stack system could help with that (https://github.github.com/gh-stack/guides/ui/)

Re: jj – the CLI for Jujutsu

#24

Post by shuyang »

roblabla wrote: post #23
shuyang wrote: post #21

Has 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…

I wonder if the recent github stack system could help with that ( https://github.github.com/gh-stack/guides/ui/ )

waitlist only :/ waiting to get in so i can test it out!

Re: jj – the CLI for Jujutsu

#25

Post by bananapub »

shuyang wrote: post #21

Has 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…

github added support for this in the last six hours - https://github.github.com/gh-stack/faq/#will-this-work-with-...

Re: jj – the CLI for Jujutsu

#26

Post by bombcar »

seanhunter wrote: post #11
SOLAR_FIELDS wrote: post #9

Earlier quoted context omitted.

Every time I see a statement like this I wonder what specific features of git that people feel like are terrible enough that it’s time to completely start over. Besides “the UX is kinda shit and it’s confusing to learn”, which there are many solutions for already that don’t involve reinventing a pretty good wheel.

Right. How we got git was cvs was totally terrible[1], so Linus refused to use it. Larry McEvoy persuaded Linus to use Bitkeeper for the Linux kernel development effort. After trying Bitkeeper for a while, Linus did the thing of writing v0 of git in a weekend in a response to what he saw as the shortcomings of Bitkeeper for his workflow.[2] But the point is there had already been vcs that saw wide adoption, serious a…

To be fair the "shortcomings" that spurred it on mainly were the Samba guys (or just one) reverse-engineering Bitkeeper causing the kernel free license getting pulled, which caused Linus to say "I can build my own with blackjack and pre-commit hooks" and then he did, addressing it toward his exact use case.

It gained tons of popularity mainly because of Linus being behind it; similar projects already existed when it was released.

Re: jj – the CLI for Jujutsu

#27

Post by jdkoeck »

tom_alexander wrote: post #6

I'm giving jj a try but one aspect of it I dislike is edits to files are automatically committed, so you need to defensively create empty new commits for your changes. As in, want to browse the repo from a commit 2 weeks ago? Well if you just checkout that commit and then edit a file, you've automatically changed that commit in your repo and rebased everything after it on top of your new changes. So instead you creat…

Wow, that’s a total deal breaker to me. Using git may require a complex mental model, but at least it’s not doing anything I didn’t ask for.

Re: jj – the CLI for Jujutsu

#28

Post by swoorup »

I 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 simply be able to get a tree view of all changes, which contains file which contains file changes, so I could can have marks that span multiple changes and then either `split` or `commit` or `squash` the change, idk if there is a good word for it. Right now I can only mark within a single change, and I lose it once I navigate up.

Re: jj – the CLI for Jujutsu

#30

Post by Aeolun »

throawayonthe wrote: post #16
VMG wrote: post #13

Earlier quoted context omitted.

... unless you actually want to edit a change!

well, you can do jj new , make your edit, and then do jj squash which will add the changes to the prev revision i do this for example when i want to see a specific edit highlighted in my editor, it's a nice workflow i think

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.
Post reply on HN