1.90 was just released, so this seems reasonable, and it finally lets us
use let-chains. This includes all the clippy fixups too, and some small
changes suggested by Ilya.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Closes https://github.com/jj-vcs/jj/issues/7189
Colocated repos have some advantages and some disadvantages. On the
whole, I think making Git repos colocated by default is a better
trade-off, especially for new users. With the `git.colocate` setting,
(experienced) users can easily change this according to preference.
A non-exhaustive list of pros and cons of colocated repos:
pros:
* Many code editors show the changes one is currently working on based
on Git's "dirty worktree".
* There are a lot of tools that integrate with Git which don't work at
all in non-colocated repositories.
* There are a lot of Git features that Jujutsu doesn't have yet. When
users ask for them, the answer is usually: "Just colocate your repo
and run git directly for now." It's a strength that Jujutsu can focus
on what makes it special and not have to rush the reimplementation of
every niche feature of Git. Examples: `git rebase` tracking file
renames, `git bisect`, `git tag`, `git range-diff`, submodules.
cons:
* Jujutsu performs worse in colocated repositories with lots of refs,
because of the automatic `jj git import`.
* Colocated repos make branch@git references show up in Jujutsu output,
which is usually just aesthetically displeasing or possibly even
confusing to inexperienced users.
* Interleaving jj and (mutating) git commands can lead to confusing
situations. Examples:
* Creating a commit with git instead of jj will often leave a
duplicate "work in progress" commit in Jujutsu's log.
* Some IDEs periodically run `git fetch` in the background. This can
lead to conflicted branches and divergent change IDs, something many
people struggle with.
The [vars] section is used to define the tool versions, and the tools
are only declared in each task in order to be able to run a task and
install only the required dependencies. This way
mise build:docs
only install the docs dependencies, but not the rust toolchain.
The task are organized hierarchically, allowing to run all of the tasks
in a category, for example with
mise run "check:*"
Some aliases for the most common tasks are defined in order to keep the
command line short and easy to type. For example use
mise test squash
to run all the squash tests.
Co-authored-by: Emily <artyom@artyom.me>
The flake/devShell is already configured to pull in a nightly version of
`rustfmt` which means running `rustfmt +nightly` will actually fail
(since we aren't pulling in `rustup`).
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 89d57ffb29.
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.
