Help with consistent conflicts with Gerrit /git colocated and jiri

[brunowonka]

I recently switched to jj and I keep hitting this papercut I could use help with. My flow typically consists of pushing a stack of changes to gerrit, which then get rolled one by one as checks pass. So the commits that I push get rewritten on top of the main branch as part of the commit queue.

To get new changes from upstream I run

jj new JHEAD && jiri update -gc && jiri runp -show-path-prefix setjhead.sh

where setjhead.sh is just a that parses JIRI_HEAD (roughly always the same as main@origin) and sets the bookmark JHEAD to it:

jiri_head=$(git rev-parse JIRI_HEAD)
jj bookmark set -R . -r $jiri_head JHEAD

Anyway, what always ends up happening is: I have two changes that I pushed A and B and they get merged into the main branch. They touch roughly the same lines. After updating the tree with jiri update above, I try to rebase all my changes with

jj rebase -s 'roots(mutable()~JHEAD::~empty())' -d JHEAD --skip-emptied

Before updating my tree looks like: JHEAD - A - B.
After updating I end up with: x - A - B , x ~ A' ~ B' ~ JHEAD where x was my previous bookmark for JHEAD, A' and B' are the submitted version of A and B that I have locally. Then I try the rebase command. I would like for it to see that A and B have both been merged upstream so they get emptied and abandoned (coming from git-branchless that's what I got for free). But now what I consistently get is that A rebased on JHEAD causes conflicts because it's trying to be applied on top of B'.

I end up manually abandoning these changes every time this happens, but it'd be really great if it Just Worked(™). I can't tell if this is WAI or if there's something wrong with the way I'm updating the tree or rebasing that keeps causing this.

[jennings]

When git rebases, it calculates a patch ID for each commit so it can determine whether that patch has been previously applied. I think that's what makes this Just Work with git and what it means when it outputs "skipped previously applied commit abc".

jj doesn't currently have this kind of mechanism, so if you rebase A->B on top of A'->B', and B' modified lines that were also modified in A, jj considers that a conflict.

Hopefully jj gains a similar feature, but in the meantime, one option is to use git to do the rebase. If you don't have a bookmark name already in the right place, it can be a little cumbersome:

$ jj bookmark set foo -r B
$ git switch foo
$ git rebase JHEAD
$ jj bookmark delete foo

The reason for the bookmark is so jj sees that A and B were once reachable from git but no longer are, and so it abandons them.

[scott2000]

I wonder if this is happening because Gerrit doesn't preserve the change-id header when rebasing. We actually do support something similar to the patch ID mechanism for divergent commits, so if the commits fetched from Gerrit had the same jj change ID, it would cause them to be divergent, and then I believe jj rebase should automatically abandon them?

[brunowonka]

I wonder if this is happening because Gerrit doesn't preserve the change-id header when rebasing.

The change-id header should be preserved there, but it doesn't look like jj rebase is automatically abandoning / identifying divergent changes.

I just updated to the latest version in case that's a new thing that I didn't have when I hit this.