cli git push: allow pushing explicitly named bookmarks

[senekor]

This idea was recently mentioned again. There was a feature request about it, but it was closed as a duplicate of the discussion about auto-tracking bookmarks. In the preceeding discussion I brought up the idea that jj git push --bookmark should work for yet-untracked bookmarks. I think it was overlooked a bit because other, more important topics were being discussed in the same thread. I still think this has merit on its own, now that auto-tracking bookmarks has landed.

• 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/updated tests to cover my changes

[PhilipMetzger]

Move the PR description to the commit message, as it should be the motivation there. Since you know the project doesn't really care about PR descriptions but commit message descriptions.

[senekor]

I don't think links to various places where this issue has been talked about is interesting to people reading the commit history later? I thought it might be mildly useful context for reviewers though. I updated the commit message with a different, longer motivation.

[yuja]

iirc, the problem was that Git users would expect that the specified bookmark would be pushed to the associated upstream remote. However, jj's bookmark doesn't have a single upstream remote, and jj git push always pushes bookmarks to the default remote (or the remote specified --remote.)

[senekor]

I see, I didn't think about that... I guess the behavior that would make sense to me is:

• If the bookmark is not yet tracked with any remote, track & push it to the default remote.
• If it is tracked, but not with the default remote, and --remote was not provided, fail with a hint telling the user to provide the remote with --remote.
• If it is tracked, but not with the remote being pushed to that was provided by --remote, track & push it to the provided remote.

[yuja]

Yes, my original patch (or the second one) was something like that, but it wasn't easy to document and understand. Therefore we added --allow-new.

Also note that --bookmark can be a glob pattern. --bookmark=glob:* is roughly equivalent to --tracked as of now, and --tracked means "all bookmarks eligible to push" under the current tracking model. Perhaps, --all can be deprecated in favor of track * && push --tracked.

[senekor]

I added some more precise logic to determine when the user intent is unambiguous. I intend to add a test covering each conditional branch, but we could already discuss if we agree on the logic.

Edit: tests added