cli: bookmark: add --remote argument to track/untrack, deprecate name@remote #8244
Conversation
| let ignored_remote = default_ignored_remote_name(repo.store()) | ||
| // suppress unmatched remotes warning for default-ignored remote | ||
| .filter(|name| view.get_remote_view(name).is_some()); | ||
| let matched_refs = if args.remotes.is_none() && args.names.iter().all(|s| s.contains('@')) { |
There was a problem hiding this comment.
nit: can the args.iter().all(...) part moved into a shared helper for both track and untrack?
There was a problem hiding this comment.
You mean the let matched_refs = if ... ; block? They could be extracted to a helper function, but I think the logic will diverge later. untrack doesn't need to search "locally exists but remotely absent" bookmarks, for example.
There was a problem hiding this comment.
no, I only mean the condition since the block themselves are to different.
There was a problem hiding this comment.
I find the current this-bookmark@that-remote syntax convenient and I often use it by copy-pasting the appropriate bookmark from the jj bookmark list output. Will that output be changed, too?
Assembling the same information by hand using this-bookmark --remote that-remote feels more cumbersome. Or is the --remote part now optional if there is a unique remote with a bookmark of that name?
I think you can just copy the We could leave literal |
yuja
force-pushed
the
push-nrwpulrvyukn
branch
from
92c961d to
3876e0b
Compare
…@remote
These two are the last commands which don't support logical operators in string
patterns. The old <kind>:<name>@<remote> syntax had various problems including:
1. substring patterns look weird (e.g. `substring:x@y` means `*x*@*y*`)
2. cannot express "all but <name> for all remotes" (e.g. `(~gh-pages)@(*)`)
In addition to that, the revset parser doesn't support `<name>@<remote>`
prefixed by `<kind>:`.
This patch introduces separate --remote argument to address these problems. The
default is `glob:*` (or `~git`), so we wouldn't have to specify the remote in
many cases. One caveat is that `jj bookmark track` is not idempotent if there
are multiple remotes:
# there are two remotes: origin and upstream,
# and only foo@origin exists
$ jj bookmark track foo
# tracks foo@origin and creates new local bookmark foo
$ jj bookmark track foo
# tracks absent foo@upstream as we now have a local bookmark
This is wild. We might want to add a flag or a new command to track absent
remote bookmarks to push.
"Unmatched names" warnings are now emitted for bookmark and remote names
separately. To keep the implementation simple, the search space isn't restricted
by the other parameter. For example, "jj bookmark track foo --remote=bar" won't
show a warning if "foo" exists locally or in any remote.
Closes #4260
yuja
force-pushed
the
push-nrwpulrvyukn
branch
from
3876e0b to
03c70b0
Compare
If the remote glob works, I think that will not be needed and might indeed cause confusion. Thanks for the clarification. |
3 participants
Closes #4260
Checklist
If applicable:
CHANGELOG.mdREADME.md,docs/,demos/)cli/src/config-schema.json)