cli: branch: on create/set/rename, assume deleted tracking local branch still exists

[yuja]

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added tests to cover my changes

[ilyagr]

I am still undecided on the best possible message, but it's OK already, and that can be fixed up later. The rest of the PR LGTM.

Thank you!

[yuja]

FWIW, this PR can go away if we decide to reorganize create + set as something like set (upsert) + move.

#3584

The weirdness I'm trying to fix by this patch is that "create" preserves the existing tracking state. If the command name were "set", the behavior makes sense.

[yuja]

FWIW, this PR can go away if we decide to reorganize create + set as something like set (upsert) + move.

Created #3895

I personally prefer it over this PR since it seems more useful and will have a fewer special cases.

[ilyagr]

Wouldn't this problem affect jj branch set --new just as much as jj branch create?

[yuja]

Wouldn't this problem affect jj branch set --new just as much as jj branch create?

My feeling is that set --new is okay to preserve existing tracking state (and maybe show warning?) --new might be a bad name, but it's the flag to not move existing branches. I feel "create" has stronger guarantee.

[ilyagr]

I don't think I would agree if jj branch set --create only created branches.

If jj branch set --create creates-or-moves (aka upserts, I think) branches, this makes more sense. I'm guessing this is your preference.

Some less solidified thoughts:

This might create a (minor? not minor?) problem if the user deleted a branch mybranch, thought it was gone, and then did jj branch set --create mybranch with the intention of creating a new branch. Instead, they would get a branch that's tracked by random remote branches they didn't know about. So, this seems like a (minor?) problem with the whole upsert idea that would be avoided by having jj branch create (possibly in addition to jj branch set --create).

I am not sure this is a fatal problem. The same problem would also happen if you jj branch set --create-d a new mybranch before there were any remote-tracking branches, and then fetched from a remote that has mybranch on it. So, maybe it's OK to have the same problem in the jj branch set --create mybranch case, I'm unsure.

Finally, if jj branch set --create upserts branches, I am realizing I do have a mild preference for keeping jj branch create for one more reason. As I was writing last paragraph, it was much more natural to write "if you jj branch create mybranch" as opposed to "if you jj branch set --create-d a new mybranch".

If we keep jj branch create in any form, I do think something like this PR would be useful.

[ilyagr]

(Update: I belatedly realized I should have posted this in #3884 (comment), now this post is more or less duplicated)

As an aside, I'm pretty sure I want jj branch forget --local to exist. It's not actually exactly the same as jj branch untrack glob:branch@* if the branch exists. Once it exists, we could put it into the hints of this PR (only if we continue with this PR, of course, I was mostly thinking about this before I saw the other one).

Most likely, I'll require people to specify either --local or --global (and perhaps --from-remotes that lists specific remotes or a glob would be a third option eventually). In the long term, I think I prefer either --local being the default or there being no default.

Let me know if you prefer not doing this or find this controversial enough to benefit from filing an FR before trying to implement a PR.

[yuja]

I don't think I would agree if jj branch set --create only created branches.

If jj branch set --create creates-or-moves (aka upserts, I think) branches, this makes more sense. I'm guessing this is your preference.

My plan is:

• make jj branch set do upsert by default (i.e. create-or-move)
• add --new (or deny-move) flag for users who want to ensure that the branch doesn't exist.

The reason behind the idea is that jj config set does upsert, and if we add jj tag set, I think it would do upsert with --allow-overwrite flag or something. (It wouldn't make sense to add tag set for very narrow use case, in addition to tag create.)

This might create a (minor? not minor?) problem if the user deleted a branch mybranch, thought it was gone, and then did jj branch set --create mybranch with the intention of creating a new branch. Instead, they would get a branch that's tracked by random remote branches they didn't know about.

Yeah. That's why I think we might want some warning message.

Another reason I'm getting skeptical about this PR is that jj branch rename old new && jj branch rename new old will no longer work if old had tracking remotes and renaming back to deleted tracking branch is a hard error.

[ilyagr]

Looks great, thank you!

A few messages to fix, sorry.

[yuja]

Thanks for suggestions.