Jujutsu for everyone

This tutorial is excellent. It’d be helpful to also include how jj flows map to pull requests in the GitHub/GitLab model, since many new jj users collaborate via PRs with main protected by default.

What’s the best way to represent a stack? How do you model jj’s editing a commit at the bottom where everything above implicitly rebases when pull requests are open?

One of the most intimating things is fumbling around with your vcs when an expert is reviewing your code.

I'm having a hard time understanding your question. are you asking how people who are unfamiliar with git and jj should mentally model a stack of PRs? and that this is a problem because it's intimidating for them when an expert (in git? in the codebase?) is reviewing their code?

if yes:

while jj does make stacked PRs quite easy, I think this tutorial is mostly aimed at people who are still getting their feet wet and not making stacks of PRs. and if the expert is intimidating, tell them to be helpful or fuck off

if no:

well I don't understand your question, but probably don't `jj edit` the commit at the bottom of a stack; `jj new` and, when you're ready, either `jj squash` it down or `jj rebase -s @ -A @-` your change into the stack instead

I'll use my case as an example (though I haven't tried this yet, maybe it'll be seamless):

I'm working in a monorepo on GitHub, where PRs get squash-merged & `main` is a protected branch, and a bot automatically tags every team for review if a commit in a PR branch has changed any of their files (anything they're in an OWNERS file for), then how do I work with `jj` so as not to tag the entire company if I develop a long-running feature branch alongside several other devs on my team? We need to periodically merge in changes from `main` as the feature is developed, but don't want to merge the feature until it's ready for release. With `git`, any use of `rebase` to get changes from `main` into the feature branch causes the bot to tag every team that merged anything to `main` between the creation of the feature branch & the use of the `rebase`. I'm not on the team that controls the bot, and I don't care to try to get them to change it.

I happily use `jj` for anything I can get away with it on, but `git rebase` + monorepo + PR-centric workflow = pain, and `jj` seems like it could cause the same sort of issues. I should just try with a dummy branch & see, but that takes time & I've been busy.

Editing the commit at the bottom of the stack is part of the magic of jj since it makes it so easy. So not knowing how that works in a github workflow or what the recommendation is feels like a miss on a “jj for newbie” tutorial.

And it’s better to let each commit merge down one by one in the stack versus squashing so people can follow your development process via that stack after the fact.

Comment about expert was made off hand. If common flows break with GitHub, people are going to be hesitant to use a new tool, hurting adoption. Again, given this is a for beginner tutorial. But you make a good point about not being too sensitive ;)