How do I not get owned if another coder bases a branch on my branch? #8151
Replies: 5 comments 10 replies
-
|
Maybe you can exclude descendants of your bookmarks, but there might be other edge cases.
|
Beta Was this translation helpful? Give feedback.
-
|
I had believed that change IDs are only stored in the local |
Beta Was this translation helpful? Give feedback.
-
|
There is a related issue to this with Github's pull request refs (which require invoking
Then the old commits show up on the 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 I believe this is the same as your "Scenario 2" except that in this case the two developers are the same person! |
Beta Was this translation helpful? Give feedback.
-
|
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." |
Beta Was this translation helpful? Give feedback.
-
|
I think I've solved Scenario 2 to my satisfaction for now via 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 #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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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
ipv7branch 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_ipv7has an identical hash to the one in my ownipv7branch, 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: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
ipv7locally and have some more edits which aren't pushed yet. I dojj git fetchand get the newcarol_ipv7branch which is based on the changes I pushed earlier. It seems that the versions of some of my commits oncarol_ipv7get associated with my working change IDs since they match hashes of the outdatedipv7@originbranch.ipv7@originwould 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 fetchoperation 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.
Beta Was this translation helpful? Give feedback.
All reactions