mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2025-02-01 17:23:08 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 5
jj/lib/src/lib.rs

71 lines
1.6 KiB
Rust
Raw Normal View History

copyright: change from "Google LLC" to "The Jujutsu Authors" Let's acknowledge everyone's contributions by replacing "Google LLC" in the copyright header by "The Jujutsu Authors". If I understand correctly, it won't have any legal effect, but maybe it still helps reduce concerns from contributors (though I haven't heard any concerns). Google employees can read about Google's policy at go/releasing/contributions#copyright.
2022-11-26 23:57:50 +00:00
// Copyright 2020 The Jujutsu Authors
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
//
// 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.
docs: add docstring for `jj-lib` crate
2023-07-09 17:27:39 +00:00
//! Jujutsu version control system.
docs: warn about missing docs for `jj-lib` crate
2023-07-10 15:17:00 +00:00
#![warn(missing_docs)]
#![deny(unused_must_use)]
revsets: define grammar in pest
2021-04-14 23:54:27 +00:00
simple_op_store: hash view/operation data directly Decouples view/operation IDs from serialized forms, which are not necessarily stable. Not breaking as these IDs are persistent, never recomputed or used for integrity checking.
2022-11-11 17:33:22 +00:00
#[macro_use]
mod content_hash;
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;
index: move current implementation to default_index_store.rs The idea is that `index.rs` contains the interface, similar to `backend.rs` for commits, and `op_store.rs` for operations.
2023-03-01 05:50:04 +00:00
pub mod default_index_store;
revset: move current implementation to new module We want to allow customization of the revset engine, so it can query server indexes, for example. The current revset implementation will be our default implementation for now. What's left in the `revset` module after this commit is mostly parsing code.
2023-03-08 21:49:37 +00:00
pub mod default_revset_engine;
revset: add `default_` prefix to graph iterator module The current revset graph iterator is the default one, which the default revset engine provides.
2023-03-14 05:35:29 +00:00
pub mod default_revset_graph_iterator;
repo: add submodule_store, default impl ..and other assorted boilerplate. These are just stubs for now, but now that we've reserved the `submodule_store` subdirectory, we can start adding more functionality.
2023-05-15 22:28:55 +00:00
pub mod default_submodule_store;
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;
settings: support human-readable byte sizes for max-new-file-size
2023-08-11 19:52:58 +00:00
pub mod fmt_util;
feat(fsmonitor): Watchman filesystem monitor implementation
2023-07-08 09:23:32 +00:00
pub mod fsmonitor;
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;
revset: allow resolving change id using hex digits from reverse alphabet By separating the value spaces change ids and commit ids, we can simplify lookup of a prefix. For example, if we know that a prefix is for a change id, we don't have to try to find matching commit ids. I think it might also help new users more quickly understand that change ids are not commit ids. This commit is a step towards that separation. It allows resolving change ids by using hex digits from the back of the alphabet instead of 0-f, so 'z'='0', 'y'='1', etc, and 'k'='f'. Thanks to @ilyagr for the idea. The regular hex digits are still allowed.
2023-02-12 18:21:29 +00:00
pub mod hex_util;
templater: move id prefix shortening onto a new type I would like to copy Mercurial's way of abbreviating ids within a user-configurable revset. We would do it for both commit ids and change ids. For that feature, we need a place to keep the set of commits the revset evaluates to. This commit adds a new `IdPrefixContext` type which will eventually be that place. The new type has functions for going back and forth between full and abbreviated ids. I've updated the templater to use it.
2023-05-04 00:54:08 +00:00
pub mod id_prefix;
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
pub mod index;
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;
merge: add a generic function for resolving trivial N-way merges We already resolve merge conflicts between hunks, trees, and refs, and maybe more. They each have their own code for the handling trivial merges (where the output is equal to one of the inputs). They look surprisingly different. This commit adds a generic function for doing that. Curiously, this new implementation uses implements it in yet another way (basically using a multi-set).
2023-05-13 18:16:55 +00:00
pub mod merge;
merged_tree: introduce a type for a set of trees to merge on the fly In order to store conflicts in the commit, as conflicts between a set of trees, we want to be able merge those trees on the fly. This introduces a type for that. It has a `Merge(Conflict(Tree))` variant, where the individual trees cannot have path-level conflicts. It also has a `Legacy(Tree)` variant, which does allow path-level conflicts. I think that should help us with the migration.
2023-06-20 14:37:31 +00:00
pub mod merged_tree;
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;
fix(docs): fix protobuf job build
2023-07-10 15:42:02 +00:00
#[allow(missing_docs)]
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;
revset: extract graph-related types to separate module I'm going to add a topo-grouping iterator adapter, and the revset module is already big enough to split.
2023-07-17 11:43:33 +00:00
pub mod revset_graph;
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
pub mod rewrite;
pub mod settings;
op_heads_store: refactor into an interface and simple implemenation The implementation has some hoops to jump through because Rust does not allow `self: &Arc<Self>` on trait methods, and two of the OpHeadsStore functions need to return cloned selves. This is worked around by making the implementation type itself a wrapper around Arc<>. This is not particularly note worthy for the current implementation type where the only data copied is a PathBuf, but for extensions it is likely to be more critical that the lifetime management of the OpHeadsStore is properly maintained.
2022-12-15 22:13:00 +00:00
pub mod simple_op_heads_store;
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
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;
repo: add submodule_store, default impl ..and other assorted boilerplate. These are just stubs for now, but now that we've reserved the `submodule_store` subdirectory, we can start adding more functionality.
2023-05-15 22:28:55 +00:00
pub mod submodule_store;
import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo
2020-12-12 08:00:42 +00:00
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