This makes it possible to use `testutils` without depending on all of
`gix`.
Users of testutils without the Git feature would currently either have
to use the LocalBackend or provide their own replacement to `TestRepo`.
`jj-lib`'s test still depend on Git. Both before and after this PR,
`cargo test --no-build -p jj-lib --no-default-features` fails to
compile. This seems like a difficult problem to address; this PR merely
tries to not make the situation worse.
**Motivation**: In at least one ERSC use-case, we'd like to use `testutils`, but
the gix dependency makes tests crash with the following error:
```
[test] thread 'gitoxide.in_parallel.produce.0' panicked at code/...:
[test] there is no reactor running, must be called from the context of a Tokio 1.x runtime
```
It's not clear to me why this happens (@davidbarsky claims to have an
idea), but this PR seems like a good workaround that also decreases the
amount of things we'd need to compile.
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.
This includes the fix for
https://github.com/BurntSushi/ripgrep/issues/3127. The fix let us
optionally allow unclosed character classes in .gitignore files. It is
allowed by default when using the `GitignoreBuilder` (as we do), so we
get the fix without code changes.
I'm planning to try to add conflict labels to `MergedTree` and
`MergedTreeId`, and it will be easier to add them if both are structs
with similar methods. Since we don't support reading/writing legacy
conflicts anymore (as far as I'm aware), I think it should be safe to
delete the `MergedTreeId::Legacy` variant now.
When cloning with the branch option:
- Only the specified branch will be fetched
- The trunk alias is only set if the specified branch happens to be the default branch
- The clone fails if the branch does not exist in the remote
This comment currently says that we update all conflicted commits when
reading the derialized extra metadata, but that's not true for commits
with the `jj:trees` commit header.
Since we can now update tags internally, local and remote tags may be out of
sync in non-colocated Git repositories. "tags" template should indicate that.
This will help "jj bookmark track" know whether absent remote ref can be created
for the specified remote. "jj bookmark" subcommands shouldn't depend on
gix::Repository API.
Although we don't have "jj git tag set"/"delete" commands, this fixes weird undo
behavior #6325. The discussion in #6325 is derailed, but there would be another
issue for the "abandon unreachable" behavior.
Fixes#6325
- Added support for workspace-specific configuration using `jj config` commands.
- Introduced `--workspace` option to `jj config edit`, `jj config set`, and `jj config unset`.
- Workspace configuration file is stored in `.jj/workspace-config.toml` per workspace.
- Simplified workspace path handling logic.
- Updated documentation and test snapshots to reflect new behavior.
This improves flexibility for users working across multiple workspaces.
Co-authored-by: Eidolon <furyhunter600@gmail.com>
Co-authored-by: ase <adam@sandbergericsson.se>
Since "tracked" state doesn't exist in Git, git::import_refs() should ignore
absent->absent "changes". git::export_refs() just works because it compares only
ref targets.
This will allow us to set up tracking state and push new bookmarks in two steps
#7072.
Absent tracked remote refs are deleted with the corresponding local ref. I
originally considered this rule could be enforced by git::import/export_refs(),
but it seemed weird if absent remote refs were left when the tracking local ref
was deleted by user. Therefore, this invariant is ensured by the view API.
Since "jj bookmark track" cannot track absent remote refs yet, this patch
doesn't have UX changes that should be documented.
