With this patch, init() would no longer panic when the checkout state already
existed. This should be okay because the caller always create new workspace
directory.
Since Index is now implemented for CompositeIndex instead of &CompositeIndex,
these two functions have exactly the same signature. We no longer need a
specialized implementation to correct lifetime of the return value.
I don't have a strong feeling whether we should add "entry.commit() -> Commit"
method or forward method calls to the Commit object, but this patch implements
the former because:
a. evolution_entry.diff() should return inter diff, whereas commit.diff()
doesn't.
b. auto-labeling works if self.commit() is an explicit method call.
c. the implementation and documentation can be simple.
Tests will be added by the next patch.
Commit::is_empty() and ::parent_tree() will query index first to avoid merging
parent trees.
iirc, the Google backend has an index of changed paths, so I made the added
function return Result although the default index will never fail. I also
considered adding matcher argument, but I don't have any use case right now. I
think the Matcher API would be too abstract to construct a database query. Maybe
we should use Revset/FilesetExpression types for that purpose.
We ran into the following error when upgrading to the latest unstable
rustc at Google when compiling our internal commit backend:
```
overflow evaluating the requirement `impl futures::Future<Output = Result<jj_lib::tree::Tree, jj_lib::backend::BackendError>>: Sized`
```
It seems to be some limitation of rustc related to recursion and async
functions but we don't know what exactly it means.
This patch works around that by making the async part of
`merge_commit_trees_no_resolve_without_repo()` non-recursive. There is
still a recursive part, but it's no longer async. The recursive part
now finds all the commit IDs involved. Then we do the lookup of them
afterwards.
We may want to make the remaining recursive part non-recursive as well
so don't run out of stack on a long braid of criss-cross merges, but
that can come later.
We didn't seem to have a test case of the recursive merge
implementation (no tests failed when I changed it to always use the
first ancestor instead of being recursive).
By default `git clone` will fetch all tags on a remote (unless
`--no-tags` is specified). Eventually we'll want to support the same
behavior, though since we first configure a remote and then fetch, we'll
need to configure the remote with the correct *general* tag fetching
behavior, but still perform the first fetch with all tags included.
This paves the way for the semantics of `jj undo` and `jj op revert` to
evolve independently. `jj op revert` is going to stay the low-level
command to apply the inverse of any operation. The new name is
consistent with `jj revert`, which applies the inverse of a commit.
`jj undo` on the other hand is planned to become a higher-level command,
which is more similar to, say, Ctrl+Z in typical GUI applications.
Running `jj undo` repeatedly will revert progressively older operations,
allowing the user to walk backwards in time. At the same time, `jj undo`
will lose the abilitly to revert arbitrary operations, to keep its
semantics simple and intuitive.
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
The current implementation does linear search, which I think is good assuming
the size of the changed paths set is usually small. The next costly part of "jj
log PATH" is commit.empty() template on merge commits (#5411). We'll need a
public API to query changed-path index to optimize it.
This will allow us to "touch" change id without duplicating commits.
The caller should also do .generate_new_change_id() to not make commits
divergent. This function could do that automatically, but I'm not sure if that's
good. Alternatively, we can add mut_repo.duplicate_commit(predecessor), but
we'll need to refactor CommitRewriter.
When checking whether a file is binary, we check if the file exists a CR
character that isn't followed by a LF character. If so, we consider this
file as binary and don't apply EOL conversion unconditionally.
This commit is related to #7010.
For some reason, running `cargo update` makes clippy notice these can
be replaced with `Self`. I put this commit first, though, since it is
helpful regardless of the update.
This is the result of the following command after the `cargo update`
from the next commit (even though the refactor is valid regardless of
the `cargo update`).
```
cargo +nightly clippy --workspace --all-targets --all-features --fix
```
Tests of the indexed contents will be added with the revset engine integration.
We don't have a public interface to get the indexed changed paths right now.
I'm going to add changed-path index, and the operation link file will store a
list of segment files and a starting commit position. Suppose the link file is
small, we wouldn't need our own serialization format.
This patch adds new directory for proto-based operation link files. We could
reuse the existing directory, but that would make debugging a bit harder.
In a future commit we'll add support for controlling a git remote's tag
fetch behavior, which may result in a `tagOpt = --[no-]tags` entry in
the remote configuration.
Doing this change here means we will avoid incorrectly flagging remote
configurations as unsupported.
Most users colocate all of their repositories or none of them. A config
option is more convenient in that situation.
There are also plans to make colocated repos the default. This change
paves the way to flip the default easily.
Closes#2507.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The problem was spotted by Martin. Since we've made remove_transitive_edges()
omit "missing" edges from the set of nodes to visit at ad7c42e04b
"revset_graph: ignore missing edges thoroughly in remove_transitive_edges()", we
should also skip them in the input set.
This patch updates all test cases to run at bit-set boundary to detect other
potential issues.
This patch implements data format, serialization, and deserialization. Actual
indexing functions and disk I/O will be added later.
The data format is simple. It's basically a sorted table of paths + pointers to
the table entries per commit. Git employs Bloom filter for this purpose, but I
don't think we need a probabilistic data structure. The size of the serialized
index segments isn't big compared to the commit index segments, and the lookup
performance seems good. It's also important that we don't need to merge parent
trees when a path matches the indexed changed paths.
With git repo (77410 commits):
- changed-path segment file size: ~1.1MB
- jj log --ignore-working-copy README.md: ~0.2sec wall
Indexing takes minutes. That's not surprising because we have to merge parent
trees to get diffs.
#4674
The problem was that the calculation of the suffix was overlapping into
the the prefix for nested directories with the same name. We skipped the
prefix to avoid this issue.
Issue: #6853
Co-authored-by: Tobias Markus <tobias@miglix.eu>
