GitHub merge and rebase creates a new commit ID causes divergent changes and jj git fetch

[weizheheng]

Wondering how the community handles merging using jj with GitHub?

I'm trying jj out and have a question on the following workflow:

1. jj new to start a new change
2. Make some changes and jj commit -m "message" to set the description and start a new change.
3. Create a bookmark with jj bookmark create name -r @-
4. jj git push --allow-new
5. Create a pull request on GitHub, and merge it with the Rebase and Merge button on the GitHub UI.
6. Somehow the commit ID is updated and no longer the same as the local version.
7. Doing jj git fetch and starts seeing divergent changes.

[scott2000]

If you delete the branch in GitHub using the "delete branch" button on the PR page after merging the PR, then jj git fetch will automatically abandon the old version of the changes that were rebased, assuming you don't have any other branches on top of them. This will avoid the divergent changes.

Otherwise, if you do have another branch on top of the rebased branch, then you can just rebase that other branch using something like jj rebase -b <other branch> -d main, and jj will automatically abandon any duplicate commits, resolving the divergence.

In the future, we'd like for this to be done automatically with a new jj sync command I believe, but it hasn't been implemented yet.

[martindemello]

doh, didn't think of that! am i right that the simplest fix is to just use plain git to push to dokku, since i never want to sync back from that?

[jennings]

No, that won't help because jj will still import dokku/main as main@dokku and consider it reachable.

I believe you're opening a pull request to merge dokku/main into origin/main? If so, the problem is that you're not deleting the branch on dokku that you're sending as a pull request.

If you create a temporary branch and delete it when the PR merges so the old commits are not reachable at all on dokku, it will probably solve the issue.

If you are opening PRs with temporary branches, how is main@dokku getting moved on top of those commits?

[martindemello]

hm, let me describe what i'm trying to do in a bit more detail.

• i'm developing locally, using jj
• i push to a repo on github, using rebase and merge. this is where i would want to collaborate with other people in the future, so i do want to pull from there back into jj
• i have a bookmark, main, which tracks what i'm pushing to dokku, but it's conceptually a one-way push - i just want to deploy to my server via dokku. i never fetch from dokku, and ideally jj would not even need to know that remote exists other than to git push to it.

[anka-213]

@martindemello Would it help if you rebased the branch on top of main@origin using jj and pushing the rebased branch prior to pressing rebase-and-merge in github? That way the "rebase-" part should be a no-op.

jj git fetch -b master --remote origin
jj rebase -b master -d master@origin
jj git push -b master --remote doku
# Press "Rebase and merge" in github

Or if you use a feature branch for you PR:

jj git fetch -b master --remote origin
jj rebase -b my-feature -d master@origin
jj git push -b my-feature --remote doku
# Press "Rebase and merge" in github

[jennings]

Oh right, Dokku is that self-hosted Heroku thing. I knew that word sounded familiar.

You actually have two different things happening:

• You have divergent changes because commits 6c2b3854 and 241561d4 are both visible.

• You have a conflicted bookmark main because you're tracking both main@origin and main@dokku. Tracking remote bookmarks means "I want my local copy of this bookmark main to synchronize with these remote bookmarks". Since the two remote bookmarks both moved, jj doesn't know where to put your local main bookmark (which is why it shows up as main??).

I would solve the second problem first by renaming main@dokku to deploy@dokku. Then you'll track deploy@dokku and it will be totally unrelated to main or main@origin.

I don't think the first issue is really a problem. You do have a branch that contains the original commit 6c2b3854, so it should be visible. I would just ignore the divergent changes. Before you next deploy, you can jj rebase -b deploy -o main --skip-emptied, which will rebase deploy onto main and abandon any now-emptied commits (which should be 6c2b3854, since the same change has already been made by 241561d4 ).

[martindemello]

nice, could this be put into a faq somewhere? i'm trying jj out, and use the rebase-and-merge workflow extensively in github, and could not find this problem referred to in any of the docs.

[fzakaria]

I would like to say that having to abandon after each PR is a bit of a bummer because I like to rebase (at least for now) on merge