cli split: Leave bookmarks associated with the original change id #5618
Conversation
cli/src/commands/split.rs
Outdated
| // If @ refers to the target commit, move it to the second commit. | ||
| if at.id() == commit.id() { | ||
| tx.edit(&second_commit)?; | ||
| } |
There was a problem hiding this comment.
This will update working copies in other workspaces. I think we should update the code here (lines 207-235) to use rewrite::move_commits() in order to move the children of commit (i.e. before splitting) to be rebased on top of second_commit.
There was a problem hiding this comment.
it would also be nice if you spelled out "the working copy commit (@)" in the comment
There was a problem hiding this comment.
I'm not sure I understand. How will using rewrite::move_commits() avoid the issue of edit updating the working copy in other workspaces? I need to read up on how workspaces work, but I'm a little surprised that tx.edit updates workspaces other than the current one.
The code suggests it only acts on the current workspace via the workspace_id?
pub fn edit(&mut self, commit: &Commit) -> Result<(), EditCommitError> {
let workspace_id = self.helper.workspace_id().to_owned();
self.id_prefix_context.take(); // invalidate
self.tx.repo_mut().edit(workspace_id, commit)
}Separately, what should I pass to the targets argument of rewrite::move_commits()? I don't think I have a list of the children of the commit being split. Do I need to evaluate a revset, or is there another way to do it?
There was a problem hiding this comment.
How will using
rewrite::move_commits()avoid the issue ofeditupdating the working copy in other workspaces?
Oh, you're right, it won't. I was thinking that this was a workaround for how we rewrite commits in a strange way above, but it's just a consequence of wanting the working copy to move to the second commit.
but I'm a little surprised that
tx.editupdates workspaces other than the current one.
It doesn't. That's the problem, kind of. If you had split a commit checked out by another workspace, then that workspace should now point to the rewritten commit.
I think the problem is that split is a bit unusual in how it rewrites the graph:
- The change id should stay on the first commit
- Bookmarks should stay on the first commit
- Working copies should move to the second commit
- Descendants should move onto the second commit
Normally they all move in the same way, and that's what building blocks like rebase_descendants() expects. But because we don't want that here, we have to do something more manually. Moving the working-copy pointers manually as you did makes sense. We should just update the code to update all working copies instead of just the current working copy.
Sorry about the confusion.
cli/src/commands/split.rs
Outdated
| // If @ refers to the target commit, move it to the second commit. | ||
| if at.id() == commit.id() { | ||
| tx.edit(&second_commit)?; | ||
| } |
There was a problem hiding this comment.
it would also be nice if you spelled out "the working copy commit (@)" in the comment
`jj split` no longer moves bookmarks to the second revision created by the split. Local bookmarks associated with the target revision will point to the first revision (which inherits the target revision's change id) created by the split afterward. Since the first revision inherits the change id of the target revision, this behavior is less surprising than moving the bookmark to the second revision. This no-implicit-move behavior also aligns with how `jj abandon` drops bookmarks instead of moving them to the parent revision. fixes #3419
emesterhazy
force-pushed
the
push-sksyopkrnqrs
branch
from
57aed5a to
c92fa61
Compare
Makes sense; done. Thanks for taking a look :) |
martinvonz
changed the title
jj splitno longer moves bookmarks to the second revision created by the split. Local bookmarks associated with the target revision will point to the first revision (which inherits the target revision's change id) created by the split afterward.Since the first revision inherits the change id of the target revision, this behavior is less surprising than moving the bookmark to the second revision.
This no-implicit-move behavior also aligns with how
jj abandondrops bookmarks instead of moving them to the parent revision.fixes #3419
Checklist
If applicable:
CHANGELOG.md