branch set creates branches if they don't already exist?

[BatmanAoD]

Is this behavior intentional? jj set --help doesn't say anything about what happens if a branch doesn't exist, and I assumed that branches could only be created via a synchronization operation (e.g. jj git fetch) or with branch create.

❯ : jj branch set revise-result-structure-r @-  --allow-backwards
warning: Updating multiple branches (2).

❯ : jj status
The working copy is clean
Working copy : ywuxrymu 589e7dac @- revise-result-structure-r | (empty) (no description set)
Parent commit: wwqlmqkn 58ae8633 revise-result-structure | <commit message>

The fact that a branch named @- was created is especially confusing; it's probably worth forbidding branch names starting with characters that have a special meaning in the revset language, such as ~ or @.

[necauqua]

Is this behavior intentional?

Yes, although why branch create is a thing is interesting, never used it

a branch named @- was created

Also happened to me a few times, I agree this should probably fail

[ilyagr]

@arxanas, is your ideal outcome to just have jj branch set for moving, jj branch set --create (for moving and creating? Creating only?), and not jj branch create? Or do you want all three?

[ilyagr]

I had another thought about @yuja 's comment:

I slightly prefer set because jj branch move -rREV sounds a bit weird.

In addition to the idea of --to from #2555 (reply in thread), there is also an option of renaming move to update. jj branch update -rREV sounds reasonably natural to me for a command that moves branches but does not create them. Optionally, move could be an alias.

Aside: Using update instead of set (as opposed to move) might also be an option, though I'm leaning against it.

[yuja]

the best approach from a UX perspective is to add a --create flag

If "create" and "set" are mentally different, I think they should be separate commands. (i.e. just make jj branch set refuse to create new branch.)

In addition to the idea of --to from #2555 (reply in thread), there is also an option of renaming move to update.

To me, move or update sounds it would do non-trivial thing (such as rebasing the existing branch somewhere.) As for jj branch move --to REV, I would naturally think there would be --from to move branches from one revision to the other revision.

[ilyagr]

If "create" and "set" are mentally different, I think they should be separate commands. (i.e. just make jj branch set refuse to create new branch.)

This seems like it would be good enough AFAICT. I had the impression @yuja didn't like this idea, but I may have misunderstood the issue. If we can all actually be happy with it, great!

In terms of the name, if your preference is to stick with the name set, I'm completely fine with that. I suggested move because I think of this as "moving branches" but, as you pointed out, it's not as perfect a choice as I thought it was.

[arxanas]

@arxanas, is your ideal outcome to just have jj branch set for moving, jj branch set --create (for moving and creating? Creating only?), and not jj branch create? Or do you want all three?

If "create" and "set" are mentally different, I think they should be separate commands. (i.e. just make jj branch set refuse to create new branch.)

The best UX is to have jj branch create and jj branch set both exist, and (without additional options) they shouldn't overlap in functionality. That is, jj branch create should not update existing branches, and jj branch set should not create branches if they don't already exist.

I additionally meant to propose adding jj branch set --create to support workflows of current users who want that behavior, but it's not critical for the UX design itself. I can certainly imagine that some people would like to create/update the branch regardless of itself previous status, but jj branch set shouldn't do that by default.