FR: Add option to only push "current" branch

[tp-woven]

(Following the discussion here.)

Currently, jj git push either pushes all branches, or a single named branch (when used with the --branch flag). It would be convenient if there was a way to only push the "current" branch. The "use case" here is just my personal preference - at any point in time I usually have multiple "active" branches, and I rarely want to push all of them at the same time. However, having to specify the branch name every time can get a little annoying (contrast this with git push or hg uc).

Implementation-wise, one option would be querying which branches point to the current commit, and only pushing that (potentially returning an error if more than one point to the same commit).

[arxanas]

I'm curious what your workflow is in which you have multiple active branches but don't want to push all of them? I'm thinking that the desire to not do so is based on deficiencies in the tooling, and that secretly people would want to sync all their branches, if only it were safer and easier.

This is kind of like the fossil autosync workflow: https://www.fossil-scm.org/home/doc/trunk/www/concepts.wiki#workflow. At Facebook, we had something called "commit cloud" which synced all live heads across all machines, which is something I really miss and would like to recreate in git-branchless one day.

jj is uniquely suited to syncing everything all the time because, unlike any other VCS solutions on the market that I'm aware of, it can address and resolve conflicts in branch moves, not just commit contents. So it would be "safe" to sync all your branches all the time and resolve conflicts later, unlike in e.g. Git, where you wouldn't want to force-push over the remote branch if it's diverged from yours.

[tp-woven]

There are 2 cases where this comes into play (which I suppose you could think of as "tooling deficiencies"):

1. Not wanting to "publish" a certain branch yet[1] - I suppose I could simply not make a branch there, and use change/commit IDs to "navigate" within the repo, but often times branches are more convenient given current tooling/setup. Now that I think about it, though, this wasn't an issue when I was using Fig. I think the main differentiator here is that Fig was really smart about disambiguating commits based on very short SHA prefixes combined with a tmux pane that was watching the smartlog. That meant that I could both see the commit SHAs and check them out easily (i.e.: without having to resort to copy-pasting).
2. Rebases - as you say, this is less of an issue with jj, but for branches that have open PRs, I don't know that I would want to push conflicted branches blindly. Even for branches that aren't conflicted, I would prefer to first check them out and make sure the rebase is correct before pushing a new revision to GH.

Bonus 2.5. - I don't encounter this scenario very often, but sometimes when there is ongoing discussion on a PR, I may prefer to wait with pushing updates to it that might confuse reviewers.

As you say, if tooling were better, having all my work synced automatically would be great, but as long as that isn't the case, and some of the "deficient" tooling is out of my control, I still very much prefer to have control over what gets pushed and when.

[1] The issue here is a combination of having branches in a repo visible to "everyone", and our corporate policy that doesn't allow forking (even for internal repos), so you basically everyone's WIP branches which is... not ideal.