mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2024-10-25 07:56:16 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 8
jj/lib/src/lib.rs

54 lines
1.3 KiB
Rust
Raw Normal View History

import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
// Copyright 2020 Google LLC
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// https://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
revsets: define grammar in pest
2021-04-14 23:54:27 +00:00
#![deny(unused_must_use)]
store: rename Store to Backend and StoreWrapper to Store For what's currently called `Store` in the code, I have been using "backend" in plain text. That probably means that `Backend` is a good name for it.
2021-09-12 06:52:38 +00:00
pub mod backend;
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
pub mod commit;
pub mod commit_builder;
pub mod conflicts;
pub mod dag_walk;
diff: add a histogram(-like?) diff algorithm The current diff algorithm does a full LCS on the words of the texts, which is really slow. Diffing the working copy when e.g. `src/commands.py` has changes far apart takes seconds. This patch adds an implementation inspired by JGit's Histogram diff. I say "inspired" because I just didn't quite understand it :P In particular, I didn't understand what it does when it finds non-unique elements. I decided to line up the leading common elements on both sides of the merge. I don't know if that usually gives good enough results in practice. I'm sure this can still be optimized a lot, but this seems good enough as a start. There is also many things to improve about the quality of the diffs.
2021-03-20 21:44:00 +00:00
pub mod diff;
windows: don't fail when concurrent threads/processes fail to rename file On Windows, it seems that you can't rename a file if the target file is open (Stebalien/tempfile#131). I think that's the reason for our failing tests on Windows. This patch adds a simple wrapper around `NamedTempFile::persist()` that returns the existing file instead of failing, if there is one.
2021-06-14 05:54:43 +00:00
pub mod file_util;
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
pub mod files;
git: extract function for pushing commit to remote branch, and test it
2020-12-28 01:41:20 +00:00
pub mod git;
store: rename Store to Backend and StoreWrapper to Store For what's currently called `Store` in the code, I have been using "backend" in plain text. That probably means that `Backend` is a good name for it.
2021-09-12 06:52:38 +00:00
pub mod git_backend;
gitignores: add own implementation and stop using libgit2's This is to address issue #8. I haven't added the optimization to avoid walking all the files in `target/` yet. Even so, this patch still speeds up `jj st` in this repo, with ~13k files in `target/`, from ~320 ms to ~100 ms (-5.1dB). The time actually checking if paths match gitignores seems to go down from 116 ms to 6 ms. I think that's mostly because libgit2 has to look for `.gitignore` files in every parent directory every time we ask it about a file, while the rewritten code looks for a `.gitignore` file only when visiting a new directory.
2021-05-12 16:43:58 +00:00
pub mod gitignore;
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
pub mod index;
index: introduce IndexStore, which owns ReadonlyIndex files This patch introduces a new `IndexStore` struct. The idea is that it will know about the directory in which the index files are stored, the associations with operations. It may also cache `Arc<ReadonlyIndex>` instances so if multiple `ReadonlyIndex` instances are loaded, they can be returned from the cache. That may be useful when merging operations because the operations are likely to share a large parent index file. For now, however, all the new type has is `init()`, `load()`, and `reinit()`.
2021-03-03 05:43:13 +00:00
pub mod index_store;
store: rename Store to Backend and StoreWrapper to Store For what's currently called `Store` in the code, I have been using "backend" in plain text. That probably means that `Backend` is a good name for it.
2021-09-12 06:52:38 +00:00
pub mod local_backend;
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
pub mod lock;
pub mod matchers;
build: add shims for nightly feature `map_first_last`
2022-02-21 05:14:48 +00:00
pub mod nightly_shims;
view: split out separate type for keeping track of op heads
2021-03-10 23:39:16 +00:00
pub mod op_heads_store;
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
pub mod op_store;
pub mod operation;
protobuf: generate code at build-time I had tried to generate the protobuf code at build time many months ago, but decided against it because it slowed down the build too much. I didn't realize there was the "cargo:rerun-if-changed=<filename>" feature that time. Given that that exists, it seems like an obvious win to generate the source code at build time. I put the generated sources in `$OUT_DIR` (where [1] says they should be), then include them in the `protos` module by using the `include!` macro. The biggest problem with that is that I couldn't get IntelliJ to understand it, even after enabling the experimental features described in [2]. [1] https://doc.rust-lang.org/cargo/reference/build-script-examples.html#code-generation [2] https://github.com/intellij-rust/intellij-rust/issues/1908#issuecomment-592773865
2020-12-24 07:12:18 +00:00
pub mod protos;
view: add support for merging git ref targets When there are two concurrent operations, we would resolve conflicting updates of git refs quite arbitrarily before this change. This change introduces a new `refs` module with a function for doing a 3-way merge of ref targets. For example, if both sides moved a ref forward but by different amounts, we pick the descendant-most target. If we can't resolve it, we leave it as a conflict. That's fine to do for git refs because they can be resolved by simply running `jj git refresh` to import refs again (the underlying git repo is the source of truth). As with the previous change, I'm doing this now because mostly because it is a good stepping stone towards branch support (issue #21). We'll soon use the same 3-way merging for updating the local branch definition (once we add that) when a branch changes in the git repo or on a remote.
2021-07-19 06:04:21 +00:00
pub mod refs;
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
pub mod repo;
pub mod repo_path;
revsets: move code for resolving symbol to commit to new module
2021-04-05 05:56:10 +00:00
pub mod revset;
revsets: add iterator adapter for rendering simplified graph of set When rendering a non-contiguous subset of the commits, we want to still show the connections between the commits in the graph, even though they're not directly connected. This commit introduces an adaptor for the revset iterators that also yield the edges to show in such a simplified graph. This has no measurable impact on `jj log -r ,,v2.0.0` in the git.git repo. The output of `jj log -r 'v1.0.0 | v2.0.0'` now looks like this: ``` o e156455ea491 e156455ea491 gitster@pobox.com 2014-05-28 11:04:19.000 -07:00 refs/tags/v2.0.0 :\ Git 2.0 : ~ o c2f3bf071ee9 c2f3bf071ee9 junkio@cox.net 2005-12-21 00:01:00.000 -08:00 refs/tags/v1.0.0 ~ GIT 1.0.0 ``` Before this commit, it looked like this: ``` o e156455ea491 e156455ea491 gitster@pobox.com 2014-05-28 11:04:19.000 -07:00 refs/tags/v2.0.0 | Git 2.0 | o c2f3bf071ee9 c2f3bf071ee9 junkio@cox.net 2005-12-21 00:01:00.000 -08:00 refs/tags/v1.0.0 | |\ GIT 1.0.0 ``` The output of `jj log -r 'git_refs()'` in the git.git repo is still completely useless (it's >350k lines and >500MB of data). I think that's because we don't filter out edges to ancestors that we have transitive edges to. Mercurial also doesn't filter out such edges, but Git (with `--simplify-by-decoration`) seems to filter them out. I'll change it soon so we filter them out.
2021-04-24 05:55:15 +00:00
pub mod revset_graph_iterator;
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
pub mod rewrite;
pub mod settings;
pub mod simple_op_store;
stacked_table: add a file format for stacked, sorted tables I'm trying to replace the Git backend's use of Git notes for storing metadata (#7). This patch adds a file format that I hope can be used for that. It's a simple generic format for storing fixed-size keys and associated variable-size values. The keys are stored in sorted order. Each key is followed by an offset to the value. The offset is relative to the first value. All values are concatenated after each other. I suppose it's a bit like Git's pack files but lacking both delta-encoding and compression. Each file can also have a parent pointer (just like the index files have), so we don't have to rewrite the whole file each time. As with the index files, the new format squashes a file into its parent if it contains more than half the number of entries of the parent. The code is also based on `index.rs`. Perhaps we can alo replace the default operation storage with this format. Maybe also the native local backend's storage. We'll need delta-encoding and compression soon then.
2021-10-14 23:43:11 +00:00
pub mod stacked_table;
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
pub mod store;
pub mod transaction;
pub mod tree;
pub mod tree_builder;
pub mod view;
pub mod working_copy;
workspace: introduce `Workspace` type Having a concept of a "workspace" will be useful for adding support for multiple workspaces (#13). You can think of the "workspace" as a repo combined with a working copy. A workspace corresponds 1:1 with a `.jj/` directory. It's pretty close to what other VCS simply call a "repo", but I've ended up using the word "repo" for what Git calls a "bare repo".
2021-11-18 05:58:36 +00:00
pub mod workspace;
Reference in a new issue Copy permalink