FR: Stop branches from sliding back on `jj abandon`, delete them instead

[matts1]

Is your feature request related to a problem? Please describe.
Branches currently are designed to slide back when a change is deleted. @arxanas wrote:

I don't think branches should slide backwards to begin with. git-branchless deletes the branch, and I'm actually surprised to hear that Mercurial slides it backwards. Sapling also deletes the branch (regardless of whether you address the commit via hash or branch):

I have yet to see a use case which benefits from the sliding mechanism, but see many use cases that break because of it.

Consider:

◉  pvlpykyo msta 5 days ago foo 13bbdfc2
│  My local commit
◉  vzokzlpu msta 5 days ago main a2016214
│  immutable head here

If I were to write jj abandon foo, then the branch foo would instead move to main. The same thing would happen if I were to submit foo, then later run jj rebase --skip-empty.

This is a problem for multiple use cases. The first is when you want to associate each commit with a change (eg. make one commit branch be crrev.com/c/123)

Describe alternatives you've considered
I made #3482 earlier. However, this would be my preferred solution.

Additional context
Add any other context or screenshots about the feature request here.

[yuja]

Some related discussion: #1734 (comment)

fwiw, I'm +1 for this change. If jj abandon shows status/warning message about deleted branches, it wouldn't be scary to automatically remove the associated branches (which could be later pushed to remotes.)

[matts1]

That comment sounds pretty reasonable to me, but I think that you're right that if we show some kind of warning, that should eliminate those concerns.

@ilyagr as the original author of the comment, do you feel that if we added a warning you'd be ok with having it deleted?

[ilyagr]

I do often use branches in a way where branches sliding back is convenient, as I explained in #1734 (comment).

I also wonder if this should be considered together with topics (#3402). I haven't thought about that carefully, but the cases I can immediately think of where it's convenient for branches to slide back treat branches as topics, which is the kind of thinking heavily suggested by Git. This is also how I treat them 90% of the time. But perhaps splitting branch use-cases into "topic" (which I'm imagining as a set of consecutive commits, exported to Git as a branch for the tip) and "nice name for a commit" would be natural.

Overall, I don't have a conclusion. Changing the behavior with no replacement seems like it would be quite inconvenient for me. It also seems to me that this would make harder the use-cases where a branch represents a PR and PRs often consist of multiple commits. OTOH, I know that @yuja makes such PRs and doesn't like the sliding-back behavior.

It would help if I had a clearer understanding of what use-cases would be made easier by changing the behavior (the two that are clear to me are single-commit PRs and associating changelist numbers with commits) and how the changed behavior would support the use-cases that are currently easy.

---

Whether a warning is sufficient is a separate question. We have to make an educated guess whether it'd be sufficient to ensure that users don't delete important branches by accident. I don't feel like I have a clear opinion one way or another at the moment.

[necauqua]

+1 from me, actually

If jj abandon shows status/warning message about deleted branches, it wouldn't be scary

Yep, because you could jj undo it if you didn't expect that.

[..] whether it'd be sufficient to ensure that users don't delete important branches by accident

Well that's what I thought of above, jj undo mostly negates that

Moving the branch backwards only makes sense to me if branches auto-advanced, since then you'd ofren have a commit that you abandon have branches.

The typical workflow is I make a few commits on top of some commit with a branch and then only before actually having to push to a git remote do I do the jj branch set xyz -r @- dance, or just jj git push -c in case of PRs

[emesterhazy]

This seems related to two other issues regarding the movement of branches:

1. What should jj split do with bookmarks? #3419
2. FR: --advance-branches flag for jj commit #2338

I think I would personally prefer if jj never moved branches automatically and allowed me to move them freely without requiring the --allow-backwards flag. This means that jj split would conflict branches instead of moving them, among other things.

There are probably others who would prefer a more "git compatible" workflow where the branch moves forwards and backwards as commits are added and abandoned.

Maybe we can have two modes of operation controlled by a config setting. This is the direction #3129 is moving in as an experiment. Or maybe it would be better to add a separate mechanism like "aliases" that never move implicitly and then change branches so that they do move implicitly.

In any case, I think we're going to have lots of users in both camps, so we should think about how we can support both.

[ilyagr]

[..] whether it'd be sufficient to ensure that users don't delete important branches by accident

Well that's what I thought of above, jj undo mostly negates that

I agree that if there's a warning, and the user notices it immediately, undo will help.

I am more concerned about deleting the branch on the remote, if you didn't notice the warning. The branch deletion could then have happened many operations ago, and might not be easy to undo.

The typical workflow is I make a few commits on top of some commit with a branch and then only before actually having to push to a git remote do I do the jj branch set xyz -r @- dance, or just jj git push -c in case of PRs

This is a good point, thanks! This is not my workflow currently, but potentially it might work well enough.

Maybe we can have two modes of operation controlled by a config setting. This is the direction #3129 is moving in as an experiment. Or maybe it would be better to add a separate mechanism like "aliases" that never move implicitly and then change branches so that they do move implicitly.

I think this is too large a change to be governed by a config setting. For example, it will be hard to follow bug reports if people don't remember to share how they configured jj abandon. I'd prefer an option to jj abandon that performs the non-default thing.

(Update: though I also worry how many other commands we'd want to or need to add this option to. rebase --skip-empty is a candidate, though I don't use it enough to have a clear opinion).

---

Update: See Yuya's follow-up comment for an important correction/answer to this section.

Another question: what if the working copy is at a "discardable" commit (an empty commit with no descendants), has a branch at it, and you jj new another_commit. Currently, the discardable commit would be abandoned and the branch would move up. Do we want a branch to disappear in this case?

---

Another thought: if we delete branches liberally, the fact that jj branch set refuses to create branches would become annoying. We'd probably have to unify it with jj branch create again. I know that some people already want that; but the typoer that I am, I'd be a bit sad about that. (I don't think this is a major issue, though).

---

Overall, considering all the support this idea is getting, I personally would be OK with trying this as long as there's an option to jj abandon to slide branches back, and as long as we have an answer to the "discardable commits" issue and other such issues we can think of.

However, if people do not feel this is urgent, I also would prefer not rushing into this and spending some time figuring out if we can come up with a better design. I prefer a slower approach to the "try it and see if users complain" approach in this case, though again, I'm OK with doing things faster if people strongly prefer it (e.g. are really inconvenienced by the current behavior).

I still feel that while this is an improvement who dislike branches and use them minimally, it would be a step back for people who use the GitHub PR model and like PRs with many commit, which is an area where jj currently shines IMO. At this point, this is more of a feeling for me than a fully reasoned-out opinion.

[yuja]

I also worry how many other commands we'd want to or need to add this option to. rebase --skip-empty is a candidate, though I don't use it enough to have a clear opinion.

Yeah, I'm not sure whether branches should be deleted implicitly. From implementation standpoint, whether it should be handled by cmd_abandon() or rebaser.

Another question: what if the working copy is at a "discardable" commit (an empty commit with no descendants), has a branch at it, and you jj new another_commit. Currently, the discardable commit would be abandoned and the branch would move up. Do we want a branch to disappear in this case?

The current behavior is not abandoning the old working-copy commit if it had a branch #1854. This may change in future if we find a better branch movement model.

[ilyagr]

The current behavior is not abandoning the old working-copy commit if it had a branch #1854. This may change in future if we find a better branch movement model.

Thanks for the correction, good to know! This pretty much solves that issue

Yeah, I'm not sure whether branches should be deleted implicitly. From implementation standpoint, whether it should be handled by cmd_abandon() or rebaser.

I don't follow exactly, what do you mean by "deleted implicitly"?

---

After thinking about the issue of accidentally deleting branches on remote, I became more skeptical about a warning being sufficient. This is one of the few things that can lose valuable data unexpectedly (in Git, and as long as the remote is Git-based) and that jj will not help you to undo. I would really like for jj to evoke the feeling of "my data is safe, and it will be hard for me to lose it accidentally". Currently, jj git push will never delete a branch on a remote unless you did jj branch delete, I think, which helps make it easy for a user to come up with workflows that feel safe. I'm not sure there's a way around this without changing the idea significantly.

I still believe there is a problem here with the current state of jj that needs solving, but it doesn't feel urgent to me, and I'm leaning against the idea of "just have abandon delete the branch" as the solution. I'm hoping we'll get better, more complete ideas with time. (Or, perhaps, other variations of this idea are already in people's minds and I didn't understand them well enough).

If enough people feel that this is urgent, I'm happy to be overruled. It's possible that if we experiment with this idea, it'll turn out that I'm overly cautious. I might also be biased on the safety issue since I'm not inconvenienced by the current behavior.

[yuja]

Yeah, I'm not sure whether branches should be deleted implicitly. From implementation standpoint, whether it should be handled by cmd_abandon() or rebaser.

I don't follow exactly, what do you mean by "deleted implicitly"?

Commits get abandoned by e.g. --skip-empty. If I do jj abandon main..@, I expect branches within the range will be deleted. I'm not sure if I expect the same behavior with jj rebase --skip-empty.

If we expand the model of #1854, rebase --skip-empty wouldn't discard commits if local branch exists. I don't think it will be a good model implementation-wise, though.

[ilyagr]

Ah, I see, that's a good question.

[ilyagr]

What seems quite safe is to add a --delete-branches/-D option to jj abandon. I don't think this resolves for the long-term the issue of how to model branches so that they are more intuitive for more use-cases, but it might help people for now.

[ilyagr]

Re the safety issue (as opposed to the workflows issue), if we did decide to delete branches on jj abandon, we could make it pretty safe by having jj git push --all and jj git push -b 'glob:...' no longer delete branches by default.

Depending on just how safe we want to be, we could either make the user specify a --delete flag to allow deletions, or we could have a --delete flag that only allows deletions and does not permit pushing other branch changes. Then, the user will be essentially forced to list every branch they want to delete.

This might be wrong, by my sense from https://sapling-scm.com/docs/commands/push is that this is what Sapling does. (As mentioned before in this thread and in https://sapling-scm.com/docs/commands/hide, their hide command deletes local "bookmarks"; I'm not sure whether this is new or has always been the case).

[yuja]

Re the safety issue (as opposed to the workflows issue), if we did decide to delete branches on jj abandon, we could make it pretty safe by having jj git push --all and jj git push -b 'glob:...' no longer delete branches by default.

I don't think jj git push after jj abandon --delete-branches is particularly a footgun. It's equally unsafe to push the ref after it's slid down by jj abandon. That said, I'm not against changing jj git push behavior because pushing deleted refs wouldn't be that common.

[ilyagr]

It's equally unsafe to push the ref after it's slid down by jj abandon

I see it as follows:

• After a ref is slid down by jj abandon, jj git push might lose you one commit on the remote that you already expressed disinterest in.

• If jj abandon deleted the ref, and jj git push pushed the deletion automatically, you might lose a whole bunch of commits unexpectedly. For example, if you do your work on a dev branch, you might lose the entire dev branch.

• If you manually specify jj abandon --delete-branches, then you confirm that you're aware that's going to happen, so it's probably OK.

So, it seems to me like it matters a lot what the default behaviors are.