The CI system is variously hitting the limits of the existing 15 minute
build mark; in particular, Windows seems to be consistently hitting ~14m
so the chance of a runner timing out gets high if the underlying load is
also high.
While I'm working on this, let's just (regrettably) increase the slack
on the timeout so that everyone else isn't disturbed.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
'ci' is much more high-level and accurately explains what the jobs in
this test should be for. It's much more applicable than 'test' (testing
what? on what platforms?) or 'build' (does it only build? or test? or
run linters?)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Just a rename; now that `build` and `build-nix` are unified, this makes
it more clear this workflow is conceptually separate. NFC.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
There's no real reason to keep these separate and it makes the build UX
easier to navigate, too; as well as see what the actual "global" slowest
builds across all workflows easier to see.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This makes the methods and the madness a little more consistent with
each other, so it's easier to read and categorize build reports in the
GHA UX.
No functional change, but requires updating rulesets upstream.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Given the previously‐stated intention of making this default
for the 0.27 release, prepare for that decision ahead of time by
enabling subprocessing by default on trunk. This will help surface
any regressions and workflow incompatibilities and therefore give
us more information to decide whether to keep or revert this commit,
without inconveniencing any users who haven’t already opted in to
the bleeding edge.
Please feel free to revert without hesitation if any major issues
arise; this is not intended as a strong commitment to enable this
option for the next stable release if it turns out to not be ready. In
that case, it’s better that we learn that early on in the cycle,
rather than having to revert at the last minute or, worse, cutting
a stable release that we later find contains a serious regression.
This is the result of a lot of back and forth, the weekly efforts of the
governance working group, consisting of:
- Martin von Zweigbergk (martinvonz)
- Waleed Khan (arxanas)
- Emily Shaffer (nasamuffin)
- Austin Seipp (thoughtpolice; yours truly)
Many thanks as well to emeritus member Khionu Sybiern, who helped kickstart this
whole process.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
When a commit is split, the second commit produced by the split becomes the
working copy commit for all workspaces whose working copy commit was the target
of the split.
This commit adds two tests for this behavior:
1. Split a commit which is the working copy commit for two workspaces.
2. Split a commit which is the working copy commit for only one of the two
workspaces.
These tests check that the working copy commits for the workspaces are updated
correctly. Both parallel and non-parallel splits are tested.
See the discussion in #5623. This prevents future accidents if member variables
are added to RewriteRootCommit which need to be propagated to EditCommitError
during conversion.
The example became incorrect when `jj config set` stopped promoting
values with apostrophes to strings in 3f115cb. Use a TOML literal
string to fix it.
The previous name violated the "snake case" convention for variable names. I
suspect the intention was to use `RewriteRootCommit` as a type declaration, not
the argument name. Since the argument isn't used, we can use an underscore as
the name and leave the type declaration.
#cleanup
This makes the pre-release header bar into a steely blue-grey color and
changes its label, while the header for the stable docs (and past
release docs) remains indigo (blue). The goal is to make it easier to
tell prerelease docs and regular docs apart with a glance. I also
considered using a favicon with a different background, but perhaps
that's not as useful as changing the header color.
See https://github.com/jj-vcs/jj/pull/5614 for screenshots and
https://squidfunk.github.io/mkdocs-material/setup/changing-the-colors/#primary-color
for some more possibilities. "Deep purple" or "brown" are the closest
runners up to "blue grey" in my mind.
This can be tested with
```
MKDOCS_PRIMARY_COLOR="blue grey" MKDOCS_SITE_NAME="Jujutsu docs (prerelease)" uv run mkdocs serve
```
-----------
We could also want to make the historical versions more easily
distinguishable from the `latest` docs, but that would be more
difficult. We'd either need to rely on javascript or to rebuild the
*previous* version of the docs in addition to the new one on every
release.
See [mkdocs-material banner docs] for a javascript apporach (which would
still need some care in implementing, since we probably want the
prerelease version to either not have a banner or to have a different
banner).
[mkdocs-material banner docs]:
https://squidfunk.github.io/mkdocs-material/setup/setting-up-versioning/?h=version#version-warning
there are many ways to implement `heads` for your custom backend:
one involves calling `self.evaluate_revset` with a proper revset.
However, it can return an error, but `heads` does not allow it.
In our implementation of the index backend we do exactly the above
and we ended up with several unwraps which we are trying to avoid
as it could potentially crash our prod jobs.
P.S. The same logic applies to many methods in this trait, but I am doing one at a time.
One common issue that users run into with `jj undo` is that they expect
it to behave like an "undo stack", in which every consecutive `jj undo`
execution moves the current state further back in history. This is
(currently) an incorrect intuition - running multiple `jj undo` commands
back-to-back will only result in the previous non-undo change being
reverted, then un-reverted, then reverted, and so on.
This change adds a hint when the user runs `jj undo` multiple times
consecutively, suggesting that they may be looking for `jj op restore`,
which allows them to revert the whole state of the repository back to
a previous snapshot.
The previous "on this page" statement is wrong more often than not.
Unfortunately there is no "Report a vulnerability" button on
https://github.com/jj-vcs/jj/security/policy, and looking for such a
button from https://github.com/jj-vcs/jj?tab=security-ov-file leads to
confusion.
This is not the end of the world, but I don't see much security downside
to clarifying it (that is, I don't think *not* having a link protects
against phishing in any real way).
If an ellipsis arg is given to the truncate_* template functions, append (or
prepend) the ellipsis when the template content is truncated to fit the maximum
width.
Fixes#5085.
We no longer need to do cross compilation, and these instances seem
pretty fast. Enable them everywhere across the board.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
