-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Cannot export conflicted branch" when updating a merged commit #463
Comments
As I mentioned on Discord, I think this bug typically happens like this:
I think what you reported here is some version of that sequence, where the branch was deleted instead of moved. I think we want to fix two things:
|
This was referenced Oct 29, 2022
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
This is a test case for #463. It's not exactly the same case, but I'm confident that the root cause is the same (that the `.jj/repo/git_export_operation_id` doesn't include the git refs we just updated).
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
To fix #463, I think we want to skip conflicted branches when we export instead of erroring out. It seems we didn't have test case for the current behavior, so let's add one.
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
We had very little testing of the colocated case, so let's add a bit more before I start working on this code in coming patches. This includes a test for #463.
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
In order to fix #463, I'm going to make us export to Git a little earlier, before finishing the transation. That means we won't have an operation yet, but we don't need that anyway.
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
As I said in the previous patch, I don't know why I made the initial export to Git a no-op. Exporting everything makes more sense to (current-)me. It will make it slightly easier to skip exporting conflicted branches (#463).
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
When we export branches to Git, we didn't update our own record of Git's refs. This frequently led to spurious conflicts in these refs (e.g. #463). This is typically what happened: 1. Import a branch pointing to commit A from Git 2. Modify the branch in jj to point to commit B 3. Export the branch to Git 4. Update the branch in Git to point to commit C 5. Import refs from Git In step 3, we forgot to update our record of the branch in the repo view's `git_refs` field. That led to the import in step 5 to think that the branch moved from A to C in Git, which conflicts with the internal branch target of B. This commit fixes the bug by updating the refs in the `MutableRepo`. Closes #463.
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
This is a test case for #463. It's not exactly the same case, but I'm confident that the root cause is the same (that the `.jj/repo/git_export_operation_id` doesn't include the git refs we just updated).
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
To fix #463, I think we want to skip conflicted branches when we export instead of erroring out. It seems we didn't have test case for the current behavior, so let's add one.
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
We had very little testing of the colocated case, so let's add a bit more before I start working on this code in coming patches. This includes a test for #463.
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
In order to fix #463, I'm going to make us export to Git a little earlier, before finishing the transation. That means we won't have an operation yet, but we don't need that anyway.
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
As I said in the previous patch, I don't know why I made the initial export to Git a no-op. Exporting everything makes more sense to (current-)me. It will make it slightly easier to skip exporting conflicted branches (#463).
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
When we export branches to Git, we didn't update our own record of Git's refs. This frequently led to spurious conflicts in these refs (e.g. #463). This is typically what happened: 1. Import a branch pointing to commit A from Git 2. Modify the branch in jj to point to commit B 3. Export the branch to Git 4. Update the branch in Git to point to commit C 5. Import refs from Git In step 3, we forgot to update our record of the branch in the repo view's `git_refs` field. That led to the import in step 5 to think that the branch moved from A to C in Git, which conflicts with the internal branch target of B. This commit fixes the bug by updating the refs in the `MutableRepo`. Closes #463.
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
This is a test case for #463. It's not exactly the same case, but I'm confident that the root cause is the same (that the `.jj/repo/git_export_operation_id` doesn't include the git refs we just updated).
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
To fix #463, I think we want to skip conflicted branches when we export instead of erroring out. It seems we didn't have test case for the current behavior, so let's add one.
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
We had very little testing of the colocated case, so let's add a bit more before I start working on this code in coming patches. This includes a test for #463.
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
In order to fix #463, I'm going to make us export to Git a little earlier, before finishing the transation. That means we won't have an operation yet, but we don't need that anyway.
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
As I said in the previous patch, I don't know why I made the initial export to Git a no-op. Exporting everything makes more sense to (current-)me. It will make it slightly easier to skip exporting conflicted branches (#463).
martinvonz
added a commit
that referenced
this issue
Nov 3, 2022
When we export branches to Git, we didn't update our own record of Git's refs. This frequently led to spurious conflicts in these refs (e.g. #463). This is typically what happened: 1. Import a branch pointing to commit A from Git 2. Modify the branch in jj to point to commit B 3. Export the branch to Git 4. Update the branch in Git to point to commit C 5. Import refs from Git In step 3, we forgot to update our record of the branch in the repo view's `git_refs` field. That led to the import in step 5 to think that the branch moved from A to C in Git, which conflicts with the internal branch target of B. This commit fixes the bug by updating the refs in the `MutableRepo`. Closes #463.
martinvonz
added a commit
that referenced
this issue
Nov 4, 2022
We had very little testing of the colocated case, so let's add a bit more before I start working on this code in coming patches. This includes a test for #463.
martinvonz
added a commit
that referenced
this issue
Nov 4, 2022
In order to fix #463, I'm going to make us export to Git a little earlier, before finishing the transation. That means we won't have an operation yet, but we don't need that anyway.
martinvonz
added a commit
that referenced
this issue
Nov 4, 2022
As I said in the previous patch, I don't know why I made the initial export to Git a no-op. Exporting everything makes more sense to (current-)me. It will make it slightly easier to skip exporting conflicted branches (#463).
martinvonz
added a commit
that referenced
this issue
Nov 4, 2022
When we export branches to Git, we didn't update our own record of Git's refs. This frequently led to spurious conflicts in these refs (e.g. #463). This is typically what happened: 1. Import a branch pointing to commit A from Git 2. Modify the branch in jj to point to commit B 3. Export the branch to Git 4. Update the branch in Git to point to commit C 5. Import refs from Git In step 3, we forgot to update our record of the branch in the repo view's `git_refs` field. That led to the import in step 5 to think that the branch moved from A to C in Git, which conflicts with the internal branch target of B. This commit fixes the bug by updating the refs in the `MutableRepo`. Closes #463.
martinvonz
added a commit
that referenced
this issue
Nov 4, 2022
This is a test case for #463. It's not exactly the same case, but I'm confident that the root cause is the same (that the `.jj/repo/git_export_operation_id` doesn't include the git refs we just updated).
martinvonz
added a commit
that referenced
this issue
Nov 4, 2022
To fix #463, I think we want to skip conflicted branches when we export instead of erroring out. It seems we didn't have test case for the current behavior, so let's add one.
martinvonz
added a commit
that referenced
this issue
Nov 4, 2022
We had very little testing of the colocated case, so let's add a bit more before I start working on this code in coming patches. This includes a test for #463.
martinvonz
added a commit
that referenced
this issue
Nov 9, 2022
To fix #463, I think we want to skip conflicted branches when we export instead of erroring out. It seems we didn't have test case for the current behavior, so let's add one.
martinvonz
added a commit
that referenced
this issue
Nov 9, 2022
We had very little testing of the colocated case, so let's add a bit more before I start working on this code in coming patches. This includes a test for #463.
martinvonz
added a commit
that referenced
this issue
Nov 9, 2022
In order to fix #463, I'm going to make us export to Git a little earlier, before finishing the transation. That means we won't have an operation yet, but we don't need that anyway.
martinvonz
added a commit
that referenced
this issue
Nov 9, 2022
As I said in the previous patch, I don't know why I made the initial export to Git a no-op. Exporting everything makes more sense to (current-)me. It will make it slightly easier to skip exporting conflicted branches (#463).
martinvonz
added a commit
that referenced
this issue
Nov 9, 2022
When we export branches to Git, we didn't update our own record of Git's refs. This frequently led to spurious conflicts in these refs (e.g. #463). This is typically what happened: 1. Import a branch pointing to commit A from Git 2. Modify the branch in jj to point to commit B 3. Export the branch to Git 4. Update the branch in Git to point to commit C 5. Import refs from Git In step 3, we forgot to update our record of the branch in the repo view's `git_refs` field. That led to the import in step 5 to think that the branch moved from A to C in Git, which conflicts with the internal branch target of B. This commit fixes the bug by updating the refs in the `MutableRepo`. Closes #463.
martinvonz
added a commit
that referenced
this issue
Nov 10, 2022
This is a test case for #463. It's not exactly the same case, but I'm confident that the root cause is the same (that the `.jj/repo/git_export_operation_id` doesn't include the git refs we just updated).
martinvonz
added a commit
that referenced
this issue
Nov 10, 2022
To fix #463, I think we want to skip conflicted branches when we export instead of erroring out. It seems we didn't have test case for the current behavior, so let's add one.
martinvonz
added a commit
that referenced
this issue
Nov 10, 2022
We had very little testing of the colocated case, so let's add a bit more before I start working on this code in coming patches. This includes a test for #463.
martinvonz
added a commit
that referenced
this issue
Nov 10, 2022
In order to fix #463, I'm going to make us export to Git a little earlier, before finishing the transation. That means we won't have an operation yet, but we don't need that anyway.
martinvonz
added a commit
that referenced
this issue
Nov 10, 2022
As I said in the previous patch, I don't know why I made the initial export to Git a no-op. Exporting everything makes more sense to (current-)me. It will make it slightly easier to skip exporting conflicted branches (#463). It also lets us remove a `jj export` call from `test_templater.rs`.
martinvonz
added a commit
that referenced
this issue
Nov 10, 2022
When we export branches to Git, we didn't update our own record of Git's refs. This frequently led to spurious conflicts in these refs (e.g. #463). This is typically what happened: 1. Import a branch pointing to commit A from Git 2. Modify the branch in jj to point to commit B 3. Export the branch to Git 4. Update the branch in Git to point to commit C 5. Import refs from Git In step 3, we forgot to update our record of the branch in the repo view's `git_refs` field. That led to the import in step 5 to think that the branch moved from A to C in Git, which conflicts with the internal branch target of B. This commit fixes the bug by updating the refs in the `MutableRepo`. Closes #463.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
This is a test case for #463. It's not exactly the same case, but I'm confident that the root cause is the same (that the `.jj/repo/git_export_operation_id` doesn't include the git refs we just updated).
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
To fix #463, I think we want to skip conflicted branches when we export instead of erroring out. It seems we didn't have test case for the current behavior, so let's add one.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
We had very little testing of the colocated case, so let's add a bit more before I start working on this code in coming patches. This includes a test for #463.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
In order to fix #463, I'm going to make us export to Git a little earlier, before finishing the transation. That means we won't have an operation yet, but we don't need that anyway.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
As I said in the previous patch, I don't know why I made the initial export to Git a no-op. Exporting everything makes more sense to (current-)me. It will make it slightly easier to skip exporting conflicted branches (#463). It also lets us remove a `jj export` call from `test_templater.rs`.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
When we export branches to Git, we didn't update our own record of Git's refs. This frequently led to spurious conflicts in these refs (e.g. #463). This is typically what happened: 1. Import a branch pointing to commit A from Git 2. Modify the branch in jj to point to commit B 3. Export the branch to Git 4. Update the branch in Git to point to commit C 5. Import refs from Git In step 3, we forgot to update our record of the branch in the repo view's `git_refs` field. That led to the import in step 5 to think that the branch moved from A to C in Git, which conflicts with the internal branch target of B. This commit fixes the bug by updating the refs in the `MutableRepo`. Closes #463.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
When we export branches to Git, we didn't update our own record of Git's refs. This frequently led to spurious conflicts in these refs (e.g. #463). This is typically what happened: 1. Import a branch pointing to commit A from Git 2. Modify the branch in jj to point to commit B 3. Export the branch to Git 4. Update the branch in Git to point to commit C 5. Import refs from Git In step 3, we forgot to update our record of the branch in the repo view's `git_refs` field. That led to the import in step 5 to think that the branch moved from A to C in Git, which conflicts with the internal branch target of B. This commit fixes the bug by updating the refs in the `MutableRepo`. Closes #463.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
This is a test case for #463. It's not exactly the same case, but I'm confident that the root cause is the same (that the `.jj/repo/git_export_operation_id` doesn't include the git refs we just updated).
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
To fix #463, I think we want to skip conflicted branches when we export instead of erroring out. It seems we didn't have test case for the current behavior, so let's add one.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
We had very little testing of the colocated case, so let's add a bit more before I start working on this code in coming patches. This includes a test for #463.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
In order to fix #463, I'm going to make us export to Git a little earlier, before finishing the transation. That means we won't have an operation yet, but we don't need that anyway.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
As I said in the previous patch, I don't know why I made the initial export to Git a no-op. Exporting everything makes more sense to (current-)me. It will make it slightly easier to skip exporting conflicted branches (#463). It also lets us remove a `jj export` call from `test_templater.rs`.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
When we export branches to Git, we didn't update our own record of Git's refs. This frequently led to spurious conflicts in these refs (e.g. #463). This is typically what happened: 1. Import a branch pointing to commit A from Git 2. Modify the branch in jj to point to commit B 3. Export the branch to Git 4. Update the branch in Git to point to commit C 5. Import refs from Git In step 3, we forgot to update our record of the branch in the repo view's `git_refs` field. That led to the import in step 5 to think that the branch moved from A to C in Git, which conflicts with the internal branch target of B. This commit fixes the bug by updating the refs in the `MutableRepo`. Closes #463.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
This is a test case for #463. It's not exactly the same case, but I'm confident that the root cause is the same (that the `.jj/repo/git_export_operation_id` doesn't include the git refs we just updated).
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
We had very little testing of the colocated case, so let's add a bit more before I start working on this code in coming patches. This includes a test for #463.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
In order to fix #463, I'm going to make us export to Git a little earlier, before finishing the transation. That means we won't have an operation yet, but we don't need that anyway.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
As I said in the previous patch, I don't know why I made the initial export to Git a no-op. Exporting everything makes more sense to (current-)me. It will make it slightly easier to skip exporting conflicted branches (#463). It also lets us remove a `jj export` call from `test_templater.rs`.
martinvonz
added a commit
that referenced
this issue
Nov 13, 2022
When we export branches to Git, we didn't update our own record of Git's refs. This frequently led to spurious conflicts in these refs (e.g. #463). This is typically what happened: 1. Import a branch pointing to commit A from Git 2. Modify the branch in jj to point to commit B 3. Export the branch to Git 4. Update the branch in Git to point to commit C 5. Import refs from Git In step 3, we forgot to update our record of the branch in the repo view's `git_refs` field. That led to the import in step 5 to think that the branch moved from A to C in Git, which conflicts with the internal branch target of B. This commit fixes the bug by updating the refs in the `MutableRepo`. Closes #463.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
When
jj git fetch
ing a repo where one of my branches was just merged, I get a "Cannot export conflicted branch" error on the branch, and it shows up as conflicted despite no changes to the branch locally or remotely.(I've seen this a few times recently, but only now got around to "documenting" it.)
Steps to Reproduce the Problem
jj git push --change=@
).(Not sure if this is related, but)jj close
, but make no changes to the repo.jj git fetch
.Expected Behavior
main
branch should get updated from the remote, and the feature branch should get deleted.Actual Behavior
main
does get updated as expected, but the feature branch is not deleted, and instead jj reports it as being conflicted.Including the relevant
jj op log
, in case I need to get more information to debug this:Edit: Just happened again without the
jj close
shenanigans.The text was updated successfully, but these errors were encountered: