We recently renamed `jj util mangen` to `jj install-manpages` without a
deprecation warning, as it was missed in the initial PR. Waleed then
fixed it in a follow-up, which led to a longer discussion in the Discord which revealed that
not everyone was aware of it and _what_ requires a warning based deprecation.
This initially categorizes the policy into user-visible UX changes and small
impact renames, like for a small usergroup like packagers and third-party dependencies.
If we have more hickups with users, this can be expanded.
The current behaviour means (transitively) dependent crates' debug logs end up
in our logs when `--debug` is active.
The biggest offender here is `globset`, imported from the `ignore
crate`. These logs are extremely noisy and mostly irrelevant from our usecase.
This commit changes this behaviour to whitelist `jj` related debug logs,
while allowing more debugging to come from env vars
The CI seems to correctly use rustc 1.84.1 (and not 1.84.0) with this.
For reference, we last updated the MSRV to 1.76 in 5b517b5. According to
https://releases.rs/docs/1.76.0/, this was when it barely became stable.
`flake.nix` seems to be using a nightly toolchain now, so it seems there
is no need to update the version there.
The more precise clippy command used was:
cargo clippy --workspace --all-targets --fix
This adds a record of all contributing employees of companies who pay
for contributions. The purpose is to help make possible conflicts of
interest easier to spot. As far as we know, only Google currently pays
right now.
The commit guidelines feel like they're relevant before documentation
about the code review process - they could conceivably apply while
developing a change.
These often seem to get missed and raised during reviews - giving them
their own section may increase visibility.
This backs out commit 89d57ffb29577c99f0f5187b76bff369f19c5886.
This is causing a CI failure because we can't build musl binaries,
presumably because the rust-toolchain file overriding the chosen
musl toolchain for some reason. Backout until we can reapply
a proper fix.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Follow-up from discussion at https://discord.com/channels/968932220549103686/1288926971719323762
I don't think we achieved consensus in that thread. We could use `stable` or `nightly` here instead if we prefer. Note that user `rustup` overrides are still respected in the presence of a `rust-toolchain.toml`.
Our docs are built with MkDocs, which requires Python and several deps.
Previously those deps were managed with Poetry, which is also written in Python.
This commit replaces Poetry with `uv`, a Rust-based Python
project/package manager, and thus removes several steps from the docs
build process.
Before:
<install Python>
<install pipx>
pipx install poetry
poetry install
poetry run -- mkdocs serve
After:
<install uv>
uv run mkdocs serve
We didn't have any guidelines about what to include in a commit
message. Others have already written good guides for that. This commit
adds a link to one. I also added a sentence about explaining the
reason for a change, since I think that's particularly often missed
(I'm sure I also miss it sometimes - don't hesitate to point out when
that happens).
It's generally more useful to say something like "revset: use Self to
refer to expressions of the same type" than "lib: use Self to refer to
revset expressions of the same type ", so let's try to clarify that.
Jujutsu's branches do not behave like Git branches, which is a major
hurdle for people adopting it from Git. They rather behave like
Mercurial's (hg) bookmarks.
We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord,
where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were
reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name
the current mechanism. This may be hard break for current `jj branch` users, but it will immensly
help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]`
config option is currently left alone, to force not another large config update for
users, since the last time this happened was when `jj log -T show` was removed, which immediately
resulted in breaking users and introduced soft deprecations.
This name change will also make it easier to introduce Topics (#3402) as _topological branches_
with a easier model.
This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from
me being lazy or thankfully pointed out by reviewers.
I used to use "remote_branches() & ~mine()" to exclude "their" branches from
the default log, and I don't think that's uncommon requirement. Suppose
untracked branches are usually read-only, it's probably okay to make them
immutable by default.
This adds the basic outline of _when_ a Design Doc should be written. See the next
commit in the stack for the blueprint.
By adding this we hopefully can prevent unnecessary churn from new and longtime contributors,
when they want to add a major feature or rewrite a core part of Jujutsu. The text is written
as a guideline, not a rule.
I feel like recommending people install Poetry via a package manager was
a mistake. Poetry only supports its latest version, and while newer
versions are sort-of backward-compatible, they print warnings in
different situations and have different bugs. Installing `pipx` via a
package manager, OTOH, works fine, and its older versions work fine.
Using Poetry 1.8+ allows us to use Poetry's new "non-package" mode,
which would no longer print warnings if the user does `poetry install`
instead of `poetry install --no-root`. It's likely that in newer
versions of Poetry, it will become an error.
We want to avoid conflicts of interest (both real and
apparent). Better to document this before it happens.
By the way, Ilya and I both work for Google and we have approved lots
of each others' PRs, but we work in very different parts of the
company and I don't think any of the PRs have been specific to
Google's interests.
On my machine, this halves the time taken by `cargo insta test --workspace
--test-runner nextest`.
I don't believe there would be a worthwhile improvement when not
using `nextest`. I also documented how to tell whether using `mold`
is worthwhile.
I was reminded of this by https://github.com/martinvonz/jj/pull/2858.
One action publishes the 'prerelease' version on every push
to `main`.
The other publishes a 'latest' version on every releasse.
I tested both of them, but not with branch protection rules.
I initially was thinking of using `mdbook`, which looks a little better, but I
think versioning the docs is important, and the features I want are pretty much
only supported by the Mkdocs' "Material" theme.
Mkdocs is written in Python. The prerequesites for building docs on your
machine should be to install Python and Poetry, everything else should be
installed automatically by Poetry. See the edits to `contributing.md` for more details.
Summary: This was some fallout from merging #1851; I missed a few changes
I needed to back out for an upcoming diff.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I1fcdce228dea730ad7c73ad1f05facda
Summary: Let's be more aggressive about tracking the latest stable Rust release.
There's little benefit to being conservative so early on, especially when no
users seem to have faced any issue with upgrading, or strictly required an old
Rust version.
Right now, just lagging Rust by 1 major release probably seems fine. We're
targeting 1.71.0 to get ahead of the curve, since 1.72.0 will likely release
sometime before the next `jj` release.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I4e691b6ba63b5b9023a75ae0a6917672
