The `grammar` macro from `pest_derive` doesn't actually interpret the given file
as relative in our case, so we have to give it the fully qualified relative path
which exists in the `buck-out/` dir.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The `grammar` macro from `pest_derive` doesn't actually interpret the given file
as relative in our case, so we have to give it the fully qualified relative path
which exists in the `buck-out/` dir.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This is needed to emit the `.rs` files into the right build directory in a
follow up diff to add `BUCK` files.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This adds a new step to the `synchronize.py` script that synchronizes
dependencies between `Cargo.toml` and `BUCK` files. In this model, Cargo remains
the source of truth.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This cfg value isn't understood by Cargo, so it needs to have the warning
suppressed by default. We could also add an entry to `build.rs` too, but not
every package has one.
To be used by upcoming diffs.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This includes a very simple script to do the synchronization between the
workspace Cargo file and the Buck2-specific Cargo file, automatically.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Summary: These will be needed for a lot of upcoming dependencies as the Reindeer
dependencies and Cargo dependencies are unified.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
`libgit2` requires `libssh2`, which in turn requires `openssl-sys`. OpenSSL is
notoriously hard to vendor for a number of reasons including its build system.
In contrast, while BoringSSL does not make compatibility guarantees, it is easy
to vendor and is designed to be used with Bazel.
The goal is that we can substitute BoringSSL for OpenSSL in `openssl-sys` as the
underlying library, and `libssh2` will still work.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This lays the basic groundwork to invoke buck2 in a way that barely works and
builds nothing.
The `jj.bzl` code will be used in some upcoming diffs to add `BUCK` files to the
various crates.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
These are basically always useful in vscode; turn them on. Note that there is an
editorconfig plugin for vscode and we do have a `.editorconfig` file but these
options aren't set due to an old intellj-rust bug.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
When building this project with [Nix/Crane](https://github.com/ipetkov/crane/discussions/693), if the `jj-cli` dependency is specified in `Cargo.toml` as a git-based crate, `cargo vendor` splits this workspace up into sub-crate directories, which causes `cargo metadata` to fail when searching for relative deps in the workspace root.
This commit simply changes how the crate version is determined, using Cargo's built-in environment variable [`CARGO_PKG_VERSION`](https://doc.rust-lang.org/cargo/reference/environment-variables.html)
MkDocs did not render this list in
https://martinvonz.github.io/jj/prerelease/config/#node-style properly
before.
I don't understand the reason; we have other lists that are formatted
similarly to how this one was, and they look fine in MkDocs. This might
be a bug in one of the MkDocs extensions for lists that we use.
Right now, renamed and copied files don't have any color in the output
of `jj status`, and it makes them stand out. I think it's reasonable to
color renamed files the same as modified files, since renaming is like
modifying the path, and to color copied files the same as added files,
since they're basically just added files that happen to have similar
contents to an existing file.
The question "How do I avoid committing changes to files?" comes up a lot in
chat, and the solution is not obvious. It will be useful to have a description
with an example we can link to.
The wording of the similar question "How can I keep my scratch files in the
repository?" was tweaked to emphasize the difference between keeping untracked
files in the workspace and keeping changes tracked files out of published
history.
This avoids cloning `UserSettings` and some other data. I haven't
attempted to measure the performance impact (I expect it's tiny); this
is more about clarifying that there are not multiple different
versions of these fields.
This wraps all the fields in `CommandHelper` in an `Rc` so
`CommandHelper` itself becomes cheap to clone (thanks to @yuja for the
idea). I'll use that next to avoid some cloning in
`WorkspaceCommandHelper`.
This helps resolve diverged refs by abandoning both sides:
D ref = [D]
|\
| C C ref = [B - D + C]
| | |
B | B | B ref = [B - D + A]
|/ |/ |
A A A A ref = [A - D + A]
This is closer to the original behavior before 5e8d7f8c "rewrite: update
references after rewriting all commits." References can move to divergent
commits, so they should propagate further if there are more rewrites. See
the inline comment for subtle behavior difference.
We could instead replay parent_mapping in topological order, but we would
still need to flatten abandon records.
"Concurrent" operations are not necessarily actually concurrent, so
"divergent" seems like a better name. And "reconcile" seems like a
better term for merging them, though we also sometimes use "merge".
Like https://github.com/martinvonz/jj/pull/4189, this allows extensions the ability to load the repo in an environment where the local filesystem is not accessible. This change allows such extensions to exist at the CLI layer where jj is invoked as a subprocess, rather than a library (common in testing).
I just choose "clru" because it already exists in our dependency tree thorough
gix. I don't think LRU is the best cache eviction policy for our use case (a
simpler FIFO-based one might be good enough?), but it wouldn't matter for CLI
or GUI use case. I don't see significant performance degradation with "jj log
--stat -n1000".
RwLock is replaced with Mutex since get() is inherently a mutable operation.
If merge-heavy history was abandoned, intermediate parent chains can have tons
of duplicates, and the process explodes soon. Instead, we can skip any parent
ids that have been remapped.
We can no longer detect cycles reliably, but I think that's okay so long as
the function terminates.
Fixes#4352
I played with max-inline-alternation = 3 for a couple of weeks, and it's pretty
good. I think somewhere between 2 and 4 is good default because one or two
remove + add sequences are easy to parse.
