When pulling from remote, propagate rewritten/abandoned commits #241
Comments
Let's say we have a simple history like this: ``` B C D \|/ A ``` Branch `main` initially points to commit B. Two concurrent operations then move the branch to commits C and D. When the two concurrent operations get merged, the branch will be recorded as pointing to "C+D-B". If a subsequent operation now abandons commit B, we would update the "removed" side of the branch conflict. That seems a little dishonest. I think the reason I did it that way was in order to not keep B visible back when having it present in the "removed" side would keep it visible (before 33bf6ce). I noticed this issue while working on #241 because `test_import_refs_reimport()` started failing. That test case is pretty much exactly the case above.
Now that I'm using GitHub PRs instead of pushing directly to the main branch, it's quite annoying to have to abandon the old commits after GitHub rebases them. This patch makes it so we compare the remote's previous heads to the new heads and abandons any commits that were removed on the remote. As usual, that means that descendants get rebased onto the closest remaining commit. This is half of #241. The other half is to detect rewritten branches and rebase on top.
Now that I'm using GitHub PRs instead of pushing directly to the main branch, it's quite annoying to have to abandon the old commits after GitHub rebases them. This patch makes it so we compare the remote's previous heads to the new heads and abandons any commits that were removed on the remote. As usual, that means that descendants get rebased onto the closest remaining commit. This is half of #241. The other half is to detect rewritten branches and rebase on top.
Let's say we have a simple history like this: ``` B C D \|/ A ``` Branch `main` initially points to commit B. Two concurrent operations then move the branch to commits C and D. When the two concurrent operations get merged, the branch will be recorded as pointing to "C+D-B". If a subsequent operation now abandons commit B, we would update the "removed" side of the branch conflict. That seems a little dishonest. I think the reason I did it that way was in order to not keep B visible back when having it present in the "removed" side would keep it visible (before 33bf6ce). I noticed this issue while working on #241 because `test_import_refs_reimport()` started failing. That test case is pretty much exactly the case above.
Now that I'm using GitHub PRs instead of pushing directly to the main branch, it's quite annoying to have to abandon the old commits after GitHub rebases them. This patch makes it so we compare the remote's previous heads to the new heads and abandons any commits that were removed on the remote. As usual, that means that descendants get rebased onto the closest remaining commit. This is half of #241. The other half is to detect rewritten branches and rebase on top.
Let's say we have a simple history like this: ``` B C D \|/ A ``` Branch `main` initially points to commit B. Two concurrent operations then move the branch to commits C and D. When the two concurrent operations get merged, the branch will be recorded as pointing to "C+D-B". If a subsequent operation now abandons commit B, we would update the "removed" side of the branch conflict. That seems a little dishonest. I think the reason I did it that way was in order to not keep B visible back when having it present in the "removed" side would keep it visible (before 33bf6ce). I noticed this issue while working on #241 because `test_import_refs_reimport()` started failing. That test case is pretty much exactly the case above.
Now that I'm using GitHub PRs instead of pushing directly to the main branch, it's quite annoying to have to abandon the old commits after GitHub rebases them. This patch makes it so we compare the remote's previous heads to the new heads and abandons any commits that were removed on the remote. As usual, that means that descendants get rebased onto the closest remaining commit. This is half of #241. The other half is to detect rewritten branches and rebase on top.
|
The current status is that we rebase descendants off of commits that were removed from the remote, but we don't rebase onto the new branch target if the branch had been rewritten. |
|
Does this mean that a deletion removes the history of it ever existing? Is that desirable? |
|
I'm not sure what you mean by "removes the history of it ever existing", so let me give an example. Let's say we clone a repo and get this history: So We then decide to fix a bug based on Now the remote repo decided to delete the I.e., change Does that answer your question? If not, can you clarify in the context of the example? |
|
I suppose from the perspective that jj does rebasing, which changes history, making it reflect the remote is the desired outcome. |
Git has garbage collection and will delete commits that are no longer referenced. However, references from reflogs count, and the reflog for HEAD gets updated quite often, so many commits are kept after losing branches pointing to them. Reflogs entries expire after 90 days by default. Note that deleting a branch leads to the reflog also getting deleted.
Yes, the operation log will still including references to deleted commits, so you can go back as many steps as you like. We actually don't have any support for GC yet (#12), so there's no expiration period like in Git. |
Description
Old commits from a remote remain in the repo after they have been deleted on the remote.
Steps to Reproduce the Problem
jj git fetch)Expected Behavior
The commits that were removed from the remote (because no branches point to them anymore) should be abandoned locally as well. The new commits that were created off of the updated/deleted branch should be rebased to the new location (if updated) or to the closes still-existing commit (if deleted).
This is closely related to #111.
Actual Behavior
The old commits stay in place.
Specifications
The text was updated successfully, but these errors were encountered: