If you have multiple remotes to push to, you might want to keep some changes
(such as security patches) in your private fork. Git CLI has one upstream remote
per branch, but jj supports multiple tracking remotes, and therefore "jj git
push" can start tracking new remotes automatically.
This patch makes new bookmarks not eligible for push by default. I considered
adding a warning, but it's not always possible to interrupt the push shortly
after a warning is emitted.
--all implies --allow-new because otherwise it's equivalent to --tracked. It's
also easier to write a conflict rule with --all/--deleted/--tracked than with
two of them.
-c/--change doesn't require --allow-new because it is the flag to create new
tracking bookmark.
#1278
There are two known limitations right now:
- Only statically known keys are suggested.
- Keys that the user did not set are still suggested for `jj config get`.
Running that suggestion may result in an error. The error message will be
appropriate though and there is some value in letting the user know that
this config value theoretically exists. Some users may try to explore what
configurations are available via the completions.
This is a workaround for command name completion. On zsh, the complete position
is specified by $_CLAP_COMPLETE_INDEX, and an empty argument isn't padded. So,
for "jj <TAB>", { args = ["jj"], index = 1 } is provided, and our expand_args()
helpfully fills in the default command "log". Since args[index] is now "log",
no other commands are listed.
This makes completions suggest aliases from the user or repository
configuration. It's more useful for long aliases that aren't used very often,
but serve the purpose of "executable documentation" of complex and useful jj
commands.
An earlier patch "resolved" aliases, meaning that any arguments following an
alias would be completed as if the normal command had been used. So it only
made sure that using aliases doesn't degrade the rest of the completions.
Commit ID: 325402dc94
