After the previous commit, `MergedTree` and `MergedTreeId` are almost
identical, with the only difference being that `MergedTree` is attached
to a `Store` instance. `MergedTreeId` is also equivalent to
`Merge<TreeId>`, since it is just a wrapper around it.
In the future, `MergedTree` might contain additional metadata like
conflict labels. Therefore, I replaced `MergedTreeId` with `MergedTree`
wherever I think it would be required to pass this additional metadata,
or where the additional methods provided by `MergedTree` would be
useful. In any remaining places, I replaced it with `Merge<TreeId>`.
I also renamed some of the `tree_id()` methods to `tree_ids()` for
consistency, since now they return a merge of individual tree IDs
instead of a single "merged tree ID". Similarly, `MergedTree` no longer
has an `id()` method, since tree IDs won't fully identify a `MergedTree`
once it contains additional metadata.
Currently, creating a `MergedTree` requires reading all of its root
trees from the store. However, this is often not actually required. For
instance, if the only reason to read the trees is to call
`MergedTree::merge`, and the merge is trivial, then there was no need to
read the trees. Changing `MergedTree` to only require a `Merge<TreeId>`
instead of a `Merge<Tree>` will make it possible to avoid reading trees
unnecessarily in these cases.
One benefit of this approach is that `Commit::tree` no longer requires
reading from the store, so it can be made synchronous and infallible,
which simplifies a lot of code.
Since reading subtrees now returns `Merge<Tree>` instead of
`MergedTree`, we can require that `MergedTree` is only used at the root
directory. This will make the next commit simpler since it won't need to
keep track of directories.
This does complicate `jj debug tree`, since it previously relied on
`MergedTree` to iterate over the entries, but since it's only used for
debugging purposes, I think it's fine to make the code more complicated
if it makes `MergedTree` simpler.
I'm planning to make `MergedTree` contain `Merge<TreeId>` instead of
`Merge<Tree>`, and these methods would all require reading a
`Merge<Tree>`, so I think it makes more sense to have them on
`Merge<Tree>` itself. Also, if `MergedTree` contains conflict labels or
other metadata in the future, it would be better to not have to clone
them each time a subtree is accessed.
The performance wouldn't matter here, but it seems better that we don't have to
deal with multiple regex patterns in match functions.
I also renamed "name" variable because it may consist of multiple path
components.
Since non-trivial matcher objects should be constructed by FilesetExpression, we
won't need a convenient constructor function. It's easier to port Vec<Regex> to
RegexSet if the patterns Vec is owned by the builder.
This enables configuration to be conditionally applied based on the
hostname set in `operation.hostname`. Users can now use
`--when.hostnames = ["host-a", "host-b"]` in their config files to apply
settings only on specific machines.
Fixes: #6441
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.
The default remote parameter of remote_bookmarks() will be derived from this
parameter. It doesn't make sense to exclude @git bookmarks if the backend isn't
Git. It's also nice that parsing tests don't depend on the feature flag.
A typical use case is to query bookmarked revisions ignoring auto-generated
bookmarks. `bookmarks() ~ bookmarks(x)` doesn't work because a revision may have
multiple bookmarks. It's also nice that we can document the default of
`remote_bookmarks()` as `remote_bookmarks(remote=~exact:"git")`.
Closes#7665
This type is akin to Revset/FilesetExpression. Unlike these, StringExpression
doesn't have Difference(x, y) node because Difference isn't any cheaper to
compute than Intersection.
Since string patterns are often parsed as revset symbols in CLI, there's no
native parser for the "string set expression".
This will be used in order to filter bookmarks by negative pattern for example.
Since "All" and "Exact" are common, they are specialized. The other patterns are
transformed to dyn Fn.
.filter_btree_map*() functions are duplicated from StringPattern. The old
functions will be removed soon.
This is part of a series of changes to make most methods on index traits
(i.e. `ChangeIdIndex`, `MutableIndex`, `ReadonlyIndex`, `Index`)
fallible. This will enable networked implementations of these traits,
which may produce I/O errors during operation. See #7825 for more
information.
This introduces another instance of the existing anti-pattern, `TODO:
indexing error shouldn't be a "BackendError"`. We're tracking this known
issue in #7849.
Closes#7825.
This is part of a series of changes to make most methods on index traits
(i.e. `ChangeIdIndex`, `MutableIndex`, `ReadonlyIndex`, `Index`)
fallible. This will enable networked implementations of these traits,
which may produce I/O errors during operation. See #7825 for more
information.
- Introduced a few more instances of the existing anti-pattern, `TODO:
indexing error shouldn't be a "BackendError"`. We're tracking this
known issue in #7849.
- Converted `MutableRepo::merge_view` to return a `RepoLoaderError`
instead of a `BackendError`. The only caller, `MutableRepo::merge`,
already returns a `RepoLoaderError`.
- Added three "`fallible_`" iterator helpers to reduce the amount of
noise at `is_ancestor` call sites due to the method now being
fallible. Using these helpers seem to produce code that's a little
more readable than using `process_results` from itertools. One
consideration in this trade-off is that these helpers do not
themselves return iterators: if we find that we need more support for
fallible combinators mid-"chain" of iterator combinators, we might
either want to use `process_results` only in those cases, or switch to
use of `process_results` across the board (in lieu of these new
helpers).
Although rare, it would be very confusing to a user if they encountered
a conflict with a `-------` marker while using the "diff" style. This
addresses a TODO in the test.
This change was motived by the next Gitoxide version adding an
additional lifetime to `gix::reference::iter::Iter`, which currently
breaks the automated Dependabot upgrade.
I left annonymous lifetime annotations on ref-like types like
`RemoteRefSymbol`.
We want to eventually stop writing predecessors in the commit object
since we now have them in the operation object. That will expose some
problems with creating cycles between commits. This patch adds a
config option for not recording predecessors in commits so we can
start testing and fixing those issues.
We were sometimes seeing crashes at Google when a commit was rewritten
very quickly without any changes. This should prevent the crashes and
return an error to the user instead.
A sibling team of my team sometimes runs into panics caused by cycles
in the commit graph. This patch removes the panics from `dag_walk` by
having all the callers pass in a `cycle_fn`. For now, the callers
panic instead.
This is part of a series of changes to make most methods on index traits
(i.e. `ChangeIdIndex`, `MutableIndex`, `ReadonlyIndex`, `Index`)
fallible. This will enable networked implementations of these traits,
which may produce I/O errors during operation. See #7825 for more
information.
This is part of a series of changes to make most methods on index traits
(i.e. `ChangeIdIndex`, `MutableIndex`, `ReadonlyIndex`, `Index`)
fallible. This will enable networked implementations of these traits,
which may produce I/O errors during operation. See #7825 for more
information.
This is part of a series of changes to make most methods on index traits
(i.e. `ChangeIdIndex`, `MutableIndex`, `ReadonlyIndex`, `Index`)
fallible. This will enable networked implementations of these traits,
which may produce I/O errors during operation. See #7825 for more
information.
checkout
See https://github.com/jj-vcs/jj/pull/7695 for motivation/background
One of the hottest paths in `jj` during checkout is `can_create_file`
and `create_parent_dirs`. Both of these functions check to ensure that
there aren't attempts to write to special directories
(`reject_reserved_existing`) which is a fairly expensive check.
This change reduces file open/close syscalls by reusing file handles
when possible.
This is part of a series of changes to make most methods on index traits
(i.e. `ChangeIdIndex`, `MutableIndex`, `ReadonlyIndex`, `Index`)
fallible. This will enable networked implementations of these traits,
which may produce I/O errors during operation. See #7825 for more
information.
This is part of a series of changes to make most methods on index traits
(i.e. `ChangeIdIndex`, `MutableIndex`, `ReadonlyIndex`, `Index`)
fallible. This will enable networked implementations of these traits,
which can produce I/O errors during operation. See #7825 for more
information.
This is part of a series of changes to make most methods on index traits
(i.e. `ChangeIdIndex`, `MutableIndex`, `ReadonlyIndex`, `Index`)
fallible. This will enable networked implementations of these traits,
which can produce I/O errors during operation. See #7825 for more
information.
By using a type alias, we match how `Backend` and `OpStore` traits
organize their errors. This will be useful as we progressively convert
more methods on `Index`, `MutableIndex`, `ReadonlyIndex`, and
`ChangeIdIndex` traits to return `Result<T, IndexError>` in order to
support networked implementations which can produce I/O failures.
This way we match how errors are organized for the other storage traits,
and we allow for networked implementations of `Index::all_heads_for_gc`
to return I/O errors.
The error is currently something like "The revset was expected to have
1 elements, but more were provided". It wasn't at first clear what
"provided" was referring to. Of course it can only really refer to the
revset, but I think we say it more clearly as "The revset has more
than the expected 1 revisions". Note that I also changed "elements" to
"revisions" to clarify that the elements are revisions.
