What should jj split do with branches?

[emesterhazy]

I'm forking this off of #2274 (comment) where Martin wrote:

I don't think that checking out the second commit is an issue (presumably we have to pick one), but perhaps we should leave any branches in a conflicted state. Thoughts?

Good question. I think it would make more sense to leave the branch in a conflicted state, but it seems like it's practically quite useful to leave it on one of the commits instead. That way it requires action from the user in some of the cases instead of all of the cases. I'd say we should leave it that way for now and change it later if we hear that it's confusing - or worse, that it leads people to push the wrong commit to a remote.

By the way, we have had a discussion internally at Google about where regular (parent/child) jj split should put the branch. It currently leaves it on the child, but it lets the parent keep the change id. We use branches for tracking code reviews at Google (I know you're at Google, @emesterhazy; I'm just providing context for others). For that use case, it's confusing that the branch doesn't follow the change id. It makes sense for the branch to move to the child in more Git-like workflows, since branches typically point to the tip of a chain of commits in Git. However, I don't want us to design a behavior that makes less sense just because it better matches Git. What do people think?

I'm going to think about this a bit more before giving an opinion, but I wanted to give this its own issue for discussion.

[emesterhazy]

I've been thinking about this a bit more and would like to propose that we change the current behavior.

Currently, the branch bookmark follows the child revision, moving forward the way branches usually do in a git workflow.

• This doesn't make a lot of sense from the jj centric viewpoint though where bookmarks are aliases for a revision / change id, and it causes issues for workflows where each change id is reviewed separately (stacked PRs and Google's internal workflow).

Instead of moving the bookmark to the child revision, I think split should leave bookmarks in place and attached to the same change id before and after the split. If users want to move the bookmark, they can. This no-implicit-move behavior aligns the change that makes abandon drop bookmarks instead of moving them to the parent revision.

@PhilipMetzger, @martinvonz What do you think?