Add a branch option to jj new

[allonsy]

Adds a new flag to jj new called branch (-b or --branch)
Passing this flag creates a new branch with the given name or sets an existing branch to the new commit

Often, in my workflow, I create a commit and a branch at the same time.
Meaning I often perform the following two commands in series:

> jj new -m "quick fix"
> jj branch c quick_fix

It would be nice to add a flag -b to jj new just like -m which also creates/sets a branch to the newly created commit like so:

jj new -m "quick fix" -b quick_fix

The setting of the branch (as opposed to creation) I'm not married to so if we want to just create new branches and error on existing branch names that is fine too.

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

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[yuja]

I'm skeptical on copying Git-like named branch workflow in general, and I don't think this is compatible with the experimental advance-branches feature (#3129). It expects the current branch is set at @-, not @. @emesterhazy any comments?

#3402 might eventually implement a proper topic-branch support, but I don't know how that will be integrated with jj new.

[emesterhazy]

I'm also a bit skeptical of porting over the git branching model, and I'm not sure we should add branch manipulation to jj new as a flag.

I wonder if the advance-branches feature that Yuya mentioned satisfies your use case. If your goal is to move a branch forward when you add commits i think it might be more convenient for doing that.

Edit: it would also be good to understand your workflow a little better. I think it's more common to create a new branch once all of the work is done, so in your example the branch command wouldn't be run until after you've made changes and added any additional commits on top of the new one you created. I guess you know you will only create one commit and want to push it to a remote for a pull request? Why not use jj git push -c in that case?

[allonsy]

@emesterhazy I think my use case is even more simple than you are thinking. I don't need to auto move branches, I, probably like quite a few people here, prefer to set branches manually when ready to update.
However, my work uses hooks on the remote side to organize various tools like jira and CI/CD. Therefore, it is often required that I spawn a branch with a specific name once I start work on a ticket. This means that I often spawn a new branch for the ticket early on as I work on items. So I always run jj new followed by jj branch for every new PR.
Then, I continue to work on the PR via the squash workflow.

I absolutely agree that we should be careful about polluting the jj new command with overloaded features that already exist. I think I got excited with the -m flag that already overloads the jj describe command a bit and said to myself why not add a -b flag for branches too.

With this in mind, if others don't share my workflow, I'm happy to just add a short script on my machines that automates this initial commit process and let jj new be as it is

[arxanas]

Separately from the issue of whether we should add a flag to jj new or not, I'll note that Git itself used to use git checkout -b (where -b presumably stands for --branch, but it's not a valid long form), but now uses git switch -c/--create. (I blindly copied the --create flag to git-branchless without thinking about it much.)

[allonsy]

Ok, so I think there are a few questions to answer here:

1. Is it worth it to add it in? I can just create an easy script on my machines to automate this if we think it's a small number of users that need this. is it clouding jj new with too many options?
2. Should this be an anti-pattern in jj? We aren't really trying to be like git.
3. Would it be worth it instead to extend jj git push to take a branch name to create as an alternative to the -c flag. Basically the same behavior but with a custom branch name rather than one based on the change id?

[yuja]

1. Is it worth it to add it in?

Maybe no? (see the comment below)

2. Should this be an anti-pattern in jj? We aren't really trying to be like git.

I don't think it's anti-pattern, but I think it's the workflow jj can't handle very well atm.

In Git, branch name is mandatory in order to keep the commits alive, so there's a reason to do multiple things by one git checkout command. jj doesn't have this restriction, so I prefer to not mix things up by adding many command options.

3. Would it be worth it instead to extend jj git push to take a branch name to create as an alternative to the -c flag. Basically the same behavior but with a custom branch name rather than one based on the change id?

iirc, there's a feature request to make it templatable. I think it'll be a config option (instead of command-line argument), but it might help if branch name can be somehow deduced from commit metadata (such as description.)

[allonsy]

I'm no longer convinced this should be merged as I haven't need it in a while, closing