Better workflow for reviewing and editing GitHub PRs?

[YaLTeR]

I've been using jj for my projects for a few months and very much enjoying it. Thanks for making such a great improvement on the git workflows!

However, I'm experiencing some friction when reviewing and/or editing GitHub pull requests into my projects. Editing is very important, I will frequently rebase and do some final edits before merging the PR. GitHub allows maintainers to push to the PR's branch by default, which is what I use here.

With regular git, my workflow is:

1. gh pr checkout 1234
2. Explore the code, do some edits and commits, maybe rebase a bit.
3. git push --force which will push straight into the PR branch on the author's repo, thanks to gh setting up a pushRemote config for the branch.

With jj, it's quite a bit more involved:

1. On the PR page, click on the source branch to get to the author's repo.
2. Copy the SSH clone URL.
3. git remote add authorname $(wl-paste)
4. git fetch authorname
5. jj b track branchname@authorname (typing this out manually, Tab-complete doesn't work here): required to make the changes mutable
6. Then I use jj-fzf to make edits, changes, rebases, etc. Update the branchname bookmark.
7. jj git push --remote authorname -b branchname

It's also a bit annoying when the author updates the PR and I pull it for a second round of review and edits:

1. git fetch authorname (jj git fetch --remote authorname works the same way here as far as I can tell)
2. In jj-fzf I now have a bookmark conflict so I need to figure out which is the new one and abandon a bunch of changes
3. Proceed with edits/changes

Also note how, compared to git and gh:

1. I'm left with configured remotes for authors of all PRs I've reviewed (not necessarily what I want).
2. If the author used the main branch for the PR, I have to additionally restore tracking of my main@origin instead of main@authorname.

My question is: can I reduce this friction somehow? Perhaps there's feature request I can follow that will improve this kind of workflow? I see #4555 but it appears to be more about creating new PRs and not reviewing/editing others' PRs.

[ilyagr]

I know that @sheremetyev is thinking about this a lot with (proprietary, but free-as-in-beer) https://visualjj.com.

See also #5388.

[joyously]

What are the git commands happening underneath gh pr checkout 1234 ?
If you were using some other foreign VCS interface for GitHub (like Mercurial or Sapling or Breezy), would you have a similar amount of friction?

[steveklabnik]

Yes, gh pr checkout is doing steps 1-5 here https://github.com/cli/cli/blob/trunk/pkg/cmd/pr/checkout/checkout.go#L177

A small difference here is that since git allows you to fetch refs directly, they take advantage of that, rather than adding a remote, etc.

[jennings]

The part of this workflow that jj can't do today is fetch and push to the special refs/pull/123/head branch that GitHub creates for pull requests. There are a few open GitHub issues that are deciding how this would work.

If you colocate your repository, you can do the fetch and push with git or gh, then use jj for everything else.

There's no shame in using git commands, that's what makes colocation such a great feature.

[arxanas]

I suspect that when the upstream PR author force-pushes a new version of the branch, you may still have to resolve a local branch conflict? But, if so, it sounds like you should always be resolving it in favor of the remote version, which is hopefully easy enough to automate/integrate into one's workflow. Or perhaps you could just clean up the old local PR state altogether and treat it as if you were checking out an entirely new PR.

[joyously]

What do the jj maintainers do, to review other author's PR?

[martinvonz]

I basically never push to someone else's PR, but I do have to go through the annoying steps of adding a remote etc. to fetch from contributors who don't push to the main repo. #4388 should help with that.

[arxanas]

What do the jj maintainers do, to review other author's PR?

I just use a colocated repo and gh pr checkout, and try to clean the branch up manually when I'm done.

[ilyagr]

See #5388 (comment) for what I do.

[YaLTeR]

An update on the workflow after a few weeks, after realizing that gh pr checkout does in fact mostly work with jj (as pointed out in comments here).

1. gh pr checkout 1234
2. Explore the code, do some edits and commits, maybe rebase a bit.
3. git checkout branch-that-gh-created: while jj generally puts my git HEAD to the correct commit, it does not explicitly put it on the git branch. Since gh pr checkout sets branch-specifc settings (pushRemote etc.), I need git to know that it is explicitly on the branch for the push to work.
4. git push --force

So it's quite a bit closer to a regular git workflow. No manual setting of remotes and such is necessary after all. Just that one git checkout step that can be non-obvious.