"jj bookmark move" no longer shows a warning for named bookmarks not pointing to
the --from revisions. I think that's okay. `move --from=REV 'PATTERN ~ main'` is
a valid use case, and "main" shouldn't be warned.
This prepares for migration to parse_union_name_patterns(). find_bookmarks*()
will be inlined, and new helper function for unmatched warnings will be added.
As a follow-up to #8115, this moves all references in the codebase to use the new website.
I didn't update the older CHANGELOG entries because I figured they're intended
to be immutable.
Deprecation warnings will be emitted for default "substring:" patterns. This
change will suppress them. Since "glob:" will be the new default, I made these
tests use "glob:" when both "exact:" and "glob:" work.
Tests for the revset filter functions aren't updated.
These commands are easy ones. The other commands error out if one of the
patterns doesn't match anything. I'll make them warn only exact patterns instead
to keep the implementation simple. I'll also add warnings to these list
commands.
This paves the way to deprecate `git.auto-local-bookmark` without
adding lots of deprecation warnings to test output snapshots.
The behavior of some tests is slightly changed, because
auto-track-bookmarks also tracks bookmarks that were created locally.
I think it just shows up in output snapshots as absent-tracked
bookmarks, without affecting what the test is about.
This configuration allows users to express a set of bookmarks that
should be automatically tracked when first encountered. This includes
on clone, fetch, create and set.
Until now, the configuration values `git.push-new-bookmarks` and
`git.auto-local-bookmark` fulfilled parts of those use cases. However,
both options represent an "all or nothing" approach. By turning them on,
users risk tracking and pushing more bookmarks than desired.
By using a bookmark pattern, users can express that they want to
auto-track bookmarks that belong to them (e.g. `glob:my-name/*`).
When `jj status` reports conflicted bookmarks, it suggests running `jj
bookmark list` for details and `jj bookmark set` to resolve the
conflict. However, it's easy to just read the first half of the hint
and run `jj bookmark list` and then not know what to do. Let's remind
the user of the hint in the `jj bookmark list` output if there are
conflicted bookmarks. It should also be useful for users who run `jj
bookmark list` out of habit (not directly because `jj status`
suggested it).
Now that bookmarks can be marked as tracked without a remote one
necessarily being present, we can preserve the tracking state of a
renamed bookmark.
An existing hint tells users to `jj git push --bookmark {new_bookmark}`
in order to rename the bookmark on the remote. That hint actually didn't
work before, because the `--allow-new` flag was required. Now that
tracked state is preserved, the existing hint becomes correct without
the `--allow-new` flag.
Colocation is about sharing the working copy between jj and git. It's
less important where the repo is stored. I therefore think we should
not call it "colocated repo". I considered renaming it to "colocated
working copy" but that sounded awkward in many places because we often
talk about the whole workspace (repo + working copy), so "In colocated
workspaces with a very large number of branches or other refs" sounds
better than "In colocated working copies with a very large number of
branches or other refs".
Once we support colocate workspaces in non-main Git worktrees, I think
this rename will be even more relevant because then all those
workspaces share the same repo but only some of them may be colocated.
This is mostly a revert of dd73b5ab7d. It closes#5374, as feedback on
the issue has shown that many longtime and new users dislike it. Martin
himself also mentioned that he wants to walk back this deprecation.
Co-authored-by: Remo Senekowitsch <remo@buenzli.dev>
Since we already have globset in transitive dependencies, this change helps
reduce the amount of dependencies. Another reason is that globset provides a
function to convert glob to regex. This is nice because we use globs to match
against strings or internal repository paths instead of platform-native paths.
The GlobPattern wrapper is boxed because globset::Glob type is relatively big.
Computed properties are removed from the serialized data. For example,
tracking ahead/behind count can be calculated by querying commits between
the target and tracking target.
I'm thinking of adding a top-level context label consistently. If we added
"commit" to the summary template (in code), the status output would be labeled
as "working_copy commit ..", whereas log entries would be labeled as "commit
working_copy ..". The latter should be more correct since the "commit" label
is global.
Now the working-copy entry is highlighted in op log and bookmark list, which
I think is good.
The usage line originally showed `--from <REVSETS>|NAMES`, which was confusing as it
could be parsed as `--from (<REVSETS> or NAMES)`, rather than the correct `(--from
<REVSETS>) or NAMES`.
The order of the two arguments are now swapped, so that Clap displays it as
`NAMES|--from <REVSETS>` instead. Using bookmark names as the move targets should be
more common anyway. This is also consistent with the order in which the two arguments
are described in the command's doc comment.
This is the last part of the series 02722eae54 "view: port bookmark/tag name
types to RefName/RemoteName." Templater doesn't use these name types internally
because we wouldn't gain much type safety in template language.
The return type of .remote() is changed to Option<RefSymbol>. An empty symbol is
rendered with quotes, so it would be weird if local_bookmark.remote() returned
an empty RefSymbol.
We haven't had any reports of problems from people who opted in. Since
it's early in the release cycle now, let's now test it on everyone who
builds from head, so we get almost a month of testing from those
people before it's enabled by default in a released version.
This impacts lots of test cases because the change-id header is added
to the Git commit. Most are uninteresting. `test_git_fetch` now sees
some divergent changes where it used to see only divergent bookmarks,
which makes sense.
