GitHub squash-merge-based workflow

[exarkun]

I've been using jj for a few weeks on a project that is hosted on GitHub and for which the rest of the team is still using git. The project uses short-lived feature branches, GitHub PRs, and prefers squash merges onto the main branch.

I'm now just in the middle of my first experience where I have a somewhat large feature that I've decided to split into 5 PRs, each based on the previous. These each correspond to a jj revision that represent some internally consistent change to the code.

Having just squash merged the first of these PRs, I find I don't know how to reconcile jj to the new state. The first thing I don't know what to do with is that jj log shows several of the revisions in question in red with two trailing question marks, like this:

@  xrqotqst?? jeanpaul.calderone@... 2024-08-23 08:36:16 branch-name 061a565e
│  feat: add database schema for tracking stream gaps

If I try to operate on xrq then I am told:

Error: Revset "xrq" resolved to more than one revision
Hint: The revset "xrq" resolved to these revisions:
  xrqotqst?? 061a565e branch-name | feat: some words
  xrqotqst?? 8fa24c0b feat: some words
Hint: Some of these commits have the same change id. Abandon one of them with `jj abandon -r <REVISION>`.

I guess that's what the red and ?? in the log mean.

Why does xrq now resolve to more than one revision?
Is abandoning one of them the correct action to take in this scenario? Only one of them is actually available to be abandoned. If I try to abandon 8fa then jj says:

Error: Commit 8fa24c0bd970 is immutable
Hint: Pass `--ignore-immutable` or configure the set of immutable commits via `revset-aliases.immutable_heads()`.

I see that immutable_heads() is defined as trunk() | tags() | untracked_remote_branches() but I don't see why any of those would apply to this revision.

I can abandon 061 but then the whole revision is gone from my history.

Is there a good jj-based workflow for this git/GitHub workflow?

[martinvonz]

Do you know how you ended up with that divergent change? I don't think that should happen by fetching from the server after your PR was squashed. It typically happens if you perform some operation on a commit that's already been rewritten. You should be able to figure out which operation it was by running jj log -r xrq --at-op=<operation id> with various operation ids. You can find the operation ids in jj op log. Once you've figured out which operation it was, it might be easier for us to explain why that operation resulted in divergence.

The usual effect of squash merging is that jj has no way of knowing the relationship between the new upstream commit and your local commit it was created from. If you rebase your local commits onto the updated upstream main branch, it would typically result in the first commit in your chain becoming empty. You would then have to manually abandon it unless you ran jj rebase --skip-emptied.

[amiryal]

I have a conjecture about this, which I haven’t tested.

Usually, once a feature has been merged, the branch is deleted as well. However, from this:

If I try to operate on xrq then I am told:

Error: Revset "xrq" resolved to more than one revision
Hint: The revset "xrq" resolved to these revisions:
  xrqotqst?? 061a565e branch-name | feat: some words
  xrqotqst?? 8fa24c0b feat: some words
Hint: Some of these commits have the same change id. Abandon one of them with `jj abandon -r <REVISION>`.

I understand that the remote branch was not deleted on Github, but was rather updated to point to the upstream commit instead. If I remember correctly how Github’s squash merge works, then the upstream commit’s diff is identical but the commit message differs slightly. Since the remote branch is still tracked by jj locally, it tries to update xrqotqst from 061a565e to 8fa24c0b, but it fails because it wouldn’t abandon the old commit message.

As for this:

I can abandon 061 but then the whole revision is gone from my history.

Again, an untested conjecture. I suppose the new commit 8fa24c0b had already got its own change ID, so when you abandon 061a565e then xrqotqst is abandoned with it. You might try to verify it with jj log -r 8fa24c0b --at-op= in a similar way to how @martinvonz had described above.

[dbarnett]

I hit the same thing. In my case the divergence apparently started at a rebase operation:

○  1bed3ad26dd4 david@fern 21 minutes ago, lasted 76 milliseconds
│  rebase commit 8a25199104be9ac0f3f09caa2dc98faf8efd412f and descendants
│  args: jj rebase -d master@origin

and it was in relation to this merged commit: insanum/gcalcli@9444589

In this case it was a merge commit, not a squash, but I believe there might've been a rebase or something in GitHub behind the scenes because I was working with several PRs that might've had a base older than master HEAD at the time I merged them. Before that operation, my repo state was something like:

$ jj log --at-op=ae4eca729a39
@        xpmsqozp [email protected] b7097181
├─┬─┬─╮  (empty) (no description set)
│ │ ○ │  pnvkvtqk [email protected] auth_setup* ad8646d1
│ │ ├─╯  Improve auth setup experience with more self-contained explanations/links
│ ○ │  llllmwor [email protected] argcomplete* 0773d598
│ ├─╯  feat: Support shell completion using argcomplete
○ │  lxnkwmwm [email protected] tooling* HEAD@git 49b8589e
├─╯  tooling: drop flake8, configure ruff
○    lvluvxmp [email protected] add_endflag?? master* 8a251991
├─╮  (empty) Merge pull request #708 from insanum/add_endflag
│ │ ◆  lvluvxmp hidden [email protected] master@origin 94445895
├───╯  (empty) Merge pull request #708 from insanum/add_endflag
◆ │  ttyuwytk [email protected] af1c1f3d
├─╮  (empty) Merge pull request #709 from insanum/stubs

and then I tried to rebase everything onto the merged master version of that add_endflag branch and things got weird.

[martinvonz]

You have divergence already at that operation. Can you go back further in the operation log and see what caused that? jj log -r lvluvxmp --at-op=<some operation ids> should work in your case. I'm curious about the first operation that makes that command show multiple commits (i.e. divergence).

[dbarnett]

And then backing up a little further for context on what I was trying to do, in case it's helpful, I merged a PR with one commit out of 4 merge parents:

○        vluvplls 648c6b81
├─┬─┬─╮  (empty) wip: merge 'tooling', 'argcomplete', 'auth_setup', and 'add_endflag'
│ │ │ @  ykuvwnmz add_endflag* 71bb3072
│ │ │ │  Add --end flag for add command
│ │ ○ │  pnvkvtqk auth_setup 48ec11e1
│ │ ├─╯
│ ○ │  llllmwor argcomplete* eafa9d6f
│ ├─╯
○ │  lxnkwmwm tooling d4ed0bc5
├─╯

and was hoping to "sync" everything by pivoting that rev down into master and converting the 4-way merge into a 3-way merge all rebased onto that new master commit.

[dbarnett]

You're right, I guess the divergence started at this jj git fetch:

○  4fc5360338ff david@fern 56 minutes ago, lasted 1 second
│  fetch from git remote(s) origin
│  args: jj git fetch

and the state of revs was as pictured above in my previous comment.

[martinvonz]

Ah, I think I see what's going on then. I'm guessing your scenario was something like this:

$ jj log
@ l my-feature abc222
| my feeture
o k abc111 main
$ jj describe -m "my feature" # fix a typo
$ # Your local version of `l` now doesn't match the version on the remote that's about to be merged
$ jj log
@ l my-feature* abc333
| my feature
o k abc111 main
$ # You merge the branch on the remote, i.e. commit abc333
$ jj git fetch
@ l??  my-feature abc333
| my feature
| o l?? main@origin abc222
|/ my feeture
o k abc111