We need this to differentiate primary/secondary workspaces when choosing
how to colocate them (and for now, doing nothing for workspaces as
worktrees have not landed).
This commit modifies the commit graph used in the `rebase --after
--before` test case to add an additional branch of commits for use in
tests for `rebase -b` along with `--after --before`.
This commit extracts out the common code printing out the
`MoveCommitsStats` information into a shared function. The printed
output was also inconsistent between `-r` and `-s`/`-b` code paths, so I
standardized it to say "Rebased ? commits onto destination" for both
cases.
This is different from skipped paths because the file state has to remain as
FileType::GitSubmodule in order to ignore the submodule directory when
snapshotting.
Fixes#4825.
The destination commits are selected based on annotation, which I think is
basically the same as "hg absorb" (except for handling of consecutive hunks.)
However, we don't compute a full interleaved delta right now, and the hunks are
merged in the same way as "jj squash". This means absorbed hunks might produce
conflicts if no context lines exist. Still I think this is more intuitive than
selecting destination commits based on patch commutativity.
I've left inline comments to the tests where behavior is different from "hg
absorb", but these aren't exhaustively checked.
Closes#170
In "jj absorb", we'll need to calculate annotation from the parent tree. It's
usually identical to the tree of the parent commit, but this is not true for a
merge commit. Since I'm not sure how we'll process conflict trees in general,
this patch adds a minimal API to specify a single file content, not a
MergedTree.
The primary use case is to exclude immutable commits when calculating line
ranges to absorb. For example, "jj absorb" will build annotation of @ revision
with domain = mutable().
Unlike other documented aliases, it can be redefined by the user.
However, I think it's important for people to be informed that `b`
exists.
I left `amend`, `unamend`, and `ci` undocumented, since I think we were
considering removing or at least discouraging them.
Due to the gradual rewrite to use the
`MutableRepo::transform_descendants` API, `DescendantRebaser` is no
longer used in `MutableRepo::rebase_descendants`, and is only used
(indirectly through `MutableRepo::rebase_descendants_return_map`) in
`rewrite::squash_commits`.
`DescendantRebaser` is removed since it contains a lot of logic
similar to `MutableRepo::transform_descendants`. Instead,
`MutableRepo::rebase_descendants_with_options_return_map` is rewritten
to use `MutableRepo::transform_descendants` directly, and the other
`MutableRepo::rebase_descendants_{return_map,with_options}` functions
call `MutableRepo::rebase_descendants_with_options_return_map` directly.
`MutableRepo::rebase_descendants_return_rebaser` is also removed.
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.
