How do I not get owned if another coder bases a branch on my branch?

[manul-pointer]

I recently started using jj and have found that when another developer pushes a work-in-progress branch that is based on my own work-in-progress branch, it can confuse jj's heuristics in ways that disrupt my workflow, and take a lot of time to work around for a novice user. By work-in-progress branch I mean one that is not intended to be permanent or globally immutable. So I am soliciting advice on what I can do to avoid or easily work past these issues.

Let's say I'm working on the ipv7 branch to migrate our app to IPv7.
Both of the following variations have happened:

Scenario 1: Bob's branch is based on a commit which has identical Git hash to one of my local commits

Since my commit on Bob's branch bob_ipv7 has an identical hash to the one in my own ipv7 branch, it is sensibly recognized as the same commit. But this causes commits in my branch to become immutable, which is annoying. I worked around that by customizing the immutability rule to specifically exclude Bob's branch as follows:

"immutable_heads()" = "present(trunk() | tags() | (untracked_remote_bookmarks() & ~bob_ipv7@origin))"

Scenario 2: Carol's branch is based on an earlier version of my commits which were since edited/rebased

So I've been plugging away at ipv7 locally and have some more edits which aren't pushed yet. I do jj git fetch and get the new carol_ipv7 branch which is based on the changes I pushed earlier. It seems that the versions of some of my commits on carol_ipv7 get associated with my working change IDs since they match hashes of the outdated ipv7@origin branch. ipv7@origin would normally be excluded from visible commits, but Carol's branch makes its commits visible, so now I have a bunch of divergent commits. There are terrifying red letters and question marks everywhere.

I am currently working around this by undoing the jj git fetch operation and fetching only safe branches a la carte, until Carol's branch goes away. This could have worked for Scenario 1 as well, but it seems like a worse workaround. Maybe there's another config setting to make the pesky branch "invisible"?

---

Apologies if this issue been reported before. Among open issues, #762 seems to be the same as Scenario 2, but I didn't find anything about Scenario 1.

[yuja]

Maybe you can exclude descendants of your bookmarks, but there might be other edge cases.

untracked_remote_bookmarks() & ~bookmarks()::

[joyously]

Is that what the JJ maintainers do?
Shouldn't this work for everyone by default?

[manul-pointer]

I had believed that change IDs are only stored in the local .jj data base, but now I found out that they are also stored in some Git commit metadata as can be seen by git log --pretty=raw. A test with git clone shows that the IDs are followed across the clone, I assume due to this change-id metadata. So my model of how scenario 2 occurs may have been wrong. The change ID for Carol's version of my change could be getting determined by the commit metadata. Maybe I can prevent this by setting the git.write-change-id-header config option to false so that there is no change ID metadata.

[apoelstra]

There is a related issue to this with Github's pull request refs (which require invoking git fetch to obtain, see #4388). This causes divergent commits when the user does something like:

1. Creates a branch and pushes this to Github as a pull request.
2. Edits the commits locally (maybe just be rebasing) but does not push them.
3. Runs git fetch

Then the old commits show up on the pull/XYZ/head ref, causing the new ones to appear as divergent.

It is frustratingly hard to distinguish them because typically the different copies of the commit have identical metadata and may even have identical diffs. The recent change to break jj log <change id> in #6912 (now jj log 'change_id(<change id>)' with extra quotes and parens) adds UI papercuts to this already-difficult situation.

I believe this is the same as your "Scenario 2" except that in this case the two developers are the same person!

[jennings]

The reason your commits become immutable is because there is now an untracked remote bookmark that can reach them. If you want to tell jj that it's okay to mutate those comments, I would track the remote bookmark.

Yes, you'll end up with the other person's branch in your default log output, but to me, it seems like the most explicit option: tracking it says "yes I am OK with mutating these commits, even though another bookmark is pointing to them."

[apoelstra]

The problem, I think, is that from the user's point of view they're not "the same commits" (even if they literally are the same commits). They're a separate conceptual branch whose commits happen to share history with the user's branch.

I don't have a good idea of how to fix this within jj's model. It may be that the log output for divergent commits could be more explicit somehow?

[manul-pointer]

I think I've solved Scenario 2 to my satisfaction for now via jj config set git.write-change-id-header false --global. Plus jj metaedit --update-change-id 'mutable() & ::bookmarks()' which renumbers the commits from my existing branches (and also removes the change ID metadata).

Is there any benefit of loading change IDs from the commit metadata? While having change ID disabled, I tested some scenarios where branches are rewritten or get new commits both locally and on the remote, and everything works nicely. jj can detect if the branch has been modified both locally and on the remote, and indicates bookmark divergence in that case. On the other hand if only the local commits were rewritten, there is no need for the "force push" annoyance of Git when pushing. And if remote commits were rewritten but there are no local changes, the bookmark can be updated automatically unlike Git. The bookmark divergence does a good job of indicating conflicting edits; the additional change divergence just seems like a nuisance at that point, since it doesn't even tell you anything about which changes have actually differing versions, except for ruling out an initial sequence of commits with identical hashes.

Unless I'm missing something, populating change IDs from commit metadata seems largely counterproductive. Commits with duplicate IDs can be created for various random reasons such as #8151 (comment). For changes which are actually being worked on in a distributed fashion, there are tracked bookmarks. I would advise everyone to turn off git.write-change-id-header unless they use a tool that needs it. And I would redesign the Gerrit change ID thing to use a separately generated random number, unconnected to the change ID.

#4706 does propose that transporting the change ID would be useful for ease of referencing a change, but I would rather just look at the description anyway. Change IDs can drift due to squashes and splits.

[jennings]

How do you mean? After using GitHub's "Rebase and merge" on my branch then fetching, the commit in my local bookmark is marked as divergent and I have to manually rebase or delete the bookmark.

GitHub, unfortunately, does not preserve the header upon rebasing. Hopefully they do at some point.

I think GitLab and Bitbucket do, and probably Tangled.

[scott2000]

I think GitHub actually does preserve the change ID header? But there's no jj git sync command yet, so it often leads to divergent changes on fetching, making it necessary to rebase manually after fetching.

The nice thing with preserving the change ID header is that it creates divergent changes after the PR is rebase-merged, and that allows jj rebase to abandon the duplicate divergent changes automatically. If the change ID header is disabled or not preserved, then jj rebase doesn't know to abandon the duplicate commits since they end up with different change IDs.

[manul-pointer]

I had change ID headers enabled and GitHub preserved them upon rebasing. If it had not preserved them, presumably the changes would not have been marked divergent.

[manul-pointer]

The nice thing with preserving the change ID header is that it creates divergent changes after the PR is rebase-merged, and that allows jj rebase to abandon the duplicate divergent changes automatically. If the change ID header is disabled or not preserved, then jj rebase doesn't know to abandon the duplicate commits since they end up with different change IDs.

Even without change IDs, rebasing can still automatically abandon the changes as long as they are identical to the ones upstream, due to removal of commits that become empty, same as plain old Git. While if the changes are not identical, I wouldn't want them to be removed automatically. This could be a sign that, for example, I forgot to push my latest version of the changes to the forge before merging.

[scott2000]

Even without change IDs, rebasing can still automatically abandon the changes as long as they are identical to the ones upstream, due to removal of commits that become empty, same as plain old Git.

The issue with this is that we don't currently have any patch ID mechanism like Git does, so if you rebase a branch with multiple commits modifying the same file onto another branch with duplicates of those commits, then usually you'll get conflicts instead of empty commits after rebasing (since the same-change rule doesn't help in those cases) so then those commits won't be abandoned (even though their contents is identical and they should be abandoned).

We have a special case for rebasing divergent changes where it directly compares the commit diffs to any commits in the destination that have the same change ID, and abandons them if the diffs are identical. So basically preserving the change ID helps jj rebase detect duplicate commits that can be abandoned that it wouldn't currently be able to detect otherwise.