Previously, attempting to modify an immutable commit only showed the
ID of the commit being modified, which wasn't very helpful when trying
to figure out which immutable commit is being modified at a quick
glance.
This commit prints the commit summary as a hint to make it simpler for
the user to see what the immutable commit is without having to run
`jj show <commit-id>`.
https://rustsec.org/advisories/RUSTSEC-2024-0384 says to migrate off
of the `instant` crate because it's unmaintained. We depend on it only
via the `backoff` crate. That crate also seems unmaintained. So this
patch replaces our use of `backoff` by a custom implementation.
I initially intended to migrate to the `backon` crate, but that made
`lock::tests::lock_concurrent` tests fail. The test case spawns 72
threads (on my machine) and lets them all lock a file, and then it
waits 1 millisecond before releasing the file lock. I think the
problem is that their version of jitter is implemented as a random
addition of up to the initial backoff value. In our case, that means
we would add at most a millisecond. The `backoff` crate, on the other
hand does it by adding -50% to +50% of the current backoff value. I
think that leads to a much better distribution of backoffs, while
`backon`'s implementation means that only a few threads can lock the
file for each backoff exponent.
Maybe we can add comparison of ids, commits, etc., but I don't have a practical
use case right now. If we add lt/gt, it might make sense to implement them on
Timestamp type.
I also changed lhs.and_then(..) to (lhs, rhs).map(..) since we don't need
short-circuiting behavior here.
Visible aliases interfere with shell completion, at least in Fish. For
example, `jj des<tab>` stops as `jj desc` without adding a space
afterwards, which make me stop for a second and wonder if I need to
add more letters. They also show up in the auto-complete menu.
I added "[aliases: <name>]" as part of the first line of the help text
so the `jj help` output still looks the same.
The recover commit we create in some cases (when an operation has been
lost) doesn't currently have a description. That makes it easy to miss
that it's special.
When a pull request is pushed multiple times in sequence (e.g. to fix small
errors that are noticed post-submission), a backlog of builds ends up needing
to be cleared out before your new update can be built. If you push N times, N
builds are queued and need to clear out first.
This can cause higher latency for *every* PR since the pool of public runners
is shared, and in general seems uneconomical and inefficient since 99% of the
time you want to build the new version ASAP.
Luckily GHA has a universal solution to this: use the `concurrency` directive
to group all builds for a PR under a name, and when a new build appears in that
group, cancel all builds in the group that are in-progress.
Taken from this useful blog post: "Simple trick to save environment and money
when using GitHub Actions"
https://turso.tech/blog/simple-trick-to-save-environment-and-money-when-using-github-actions
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Both user and programmatic expressions use the same .evaluate() function now.
optimize() is applied globally after symbol resolution. The order shouldn't
matter, but it might be nicer because union of commit refs could be rewritten
to a single Commits(Vec<CommitId>) node.
This helps add library API that takes resolved revset expressions. For example,
"jj absorb" will first compute annotation within a user-specified ancestor range
such as "mutable()". Because the range expression may contain symbols, it should
be resolved by caller.
There are two ideas to check resolution state at compile time:
<https://github.com/martinvonz/jj/pull/4374>
a. add RevsetExpressionWrapper<PhantomState> and guarantee inner tree
consistency at public API boundary
b. parameterize RevsetExpression variant types in a way that invalid variants
can never be constructed
(a) is nice if we want to combine "resolved" and "unresolved" expressions. The
inner expression types are the same, so we can just calculate new state as
Resolved & Unresolved = Unresolved. (b) is stricter as the compiler can
guarantee invariants. This patch implements (b) because there are no existing
callers who need to construct "resolved" expression and convert it to "user"
expression.
.evaluate_programmatic() now requires that the expression is resolved.
This will become safe as I'm going to add static check that the expression does
never contain CommitRef(_)s. We could make Present(_) unconstructible, but the
existence of Present node is harmless.
I'm going to add RevsetExpression<State> type parameter, but the existing tree
transformer can't rewrite nodes to different state because the input and the
output must be of the same type. (If they were of different types, we couldn't
reuse the input subtree by Rc::clone().) The added visitor API will handle
state transitions by mapping RevsetExpression::<St1>::<Kind> to
RevsetExpression::<St2>::<Kind>.
CommitRef and AtOperation nodes are processed by specialized methods because
these nodes will depend on the State type. OTOH, Present node won't be
State-dependent, so it's inspected by the common fold_expression() method.
An input expression is not taken as an &Rc<RevsetExpression> but a &_ because
we can't reuse the allocation behind the Rc.
* Suggested `watch --color` as recommended by @ilyagr
* Answered monitoring `jj log` with watch and TUIs
* Minor wording fix.
* Adjusted watch(1) and hwatch links as suggested by @ilyagr
Signed-off-by: Tim Janik <timj@gnu.org>
The 0.23.0 release actions failed to run. Perhaps it's because I used
"save as draft" (to view the markdown) before I published it. Running
the actions on publish seems more correct.
I originally considered adding deny-list-based implementation, but the Windows
compatibility rules are super confusing and I don't have a machine to find out
possible aliases. This patch instead adds directory equivalence tests.
In order to test file entity equivalence, we first need to create a file or
directory of the requested name. It's harmless to create an empty .jj or .git
directory, but materializing .git file or symlink can temporarily set up RCE
situation. That's why new empty file is created to test the path validity. We
might want to add some optimization for safe names (e.g. ASCII, not contain
"git" or "jj", not contain "~", etc.)
That being said, I'm not pretty sure if .git/.jj in sub directory must be
checked. It's not safe to cd into the directory and run "jj", but the same
thing can be said to other tools such as "cargo". Perhaps, our minimum
requirement is to protect our metadata (= the root .jj and .git) directories.
Despite the crate name (and internal use of std::fs::File),
same_file::is_same_file() can test equivalence of directories. This is
documented and tested, so I've removed my custom implementation, which was
slightly simpler but lacks Windows support.
If new file would overwrite an existing regular file, the file path is skipped.
It makes sense to apply the same rule to existing symlinks. Without this patch,
check out would fail if an existing path was a dead symlink or a symlink to
a directory.
I'm not sure if this was attackable before, but it should be better to not
try to remove file across symlinks.
The disk_path is now returned from create_parent_dirs() to clarify that the
path is identical.
This should be safer than relying on file open error. It's scary to continue
processing if the file was a symlink.
I'll add a few more sanity checks to remove_old_file(), so it's extracted as a
function.
I'm going to add "checked" version of to_fs_path(), but all callers can't be
migrated to it. For example, an error message should be produced even if the
path is malformed.
This patch also adds error variants to propagate InvalidRepoPathError. They
don't use ::Other { .. } so the errors can be distinguished in tests.
I think `cargo publish` will currently fail because of the
`include_str!()` in `cli/src/commands/help.rs` pointing to
`../../../docs/`, i.e. outside of the crate directory. This patch
attempts to fix that creating a `cli/docs` symlink to `docs` and makes
the `include_str!` use that symlink. I hope the symlink will be
resolved at `cargo publish` time so it also works in the published
crate.
Because symlinks don't work well on Windows, I updated `cli/build.rs`
to include the original path (the one pointing outside the crate) if
`cli/docs` is not a symlink, so the regular build still should work on
Windows (but `cargo publish` won't).
Thanks to Yuya for proposing this solution.
This one is the last caller of .evaluate_programmatic() who needs symbol
resolution. Let's switch to the user revset machinery and resolve "@" as a
symbol. If this expression didn't contain "remote=<remote>" parameter, the
default would be expressed as a string RevisionArg::from("...").
I'm going to replace the current .evaluate_programmatic() which does minimal
commit-ref resolution. The new .evaluate_programmatic() will be implemented on
a "resolved" expression.