Provide a bit more detail about the JJ to Gerrit change mapping, advice
on handling splits and squashes, as well as the existing FAQ
configuration for adding Change-Id directly to change descriptions.
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>
With `all:` having gone away, some users (including me) had been using it
to enforce an invariant: by omitting it, an expression was guaranteed to
yield exactly one result. For example, this is important when using tools
like `jj rebase -B/-A`
Instead, let's fix that case by building that functionality into the
revset language itself. The previous behavior can now be enforced via
the term `exactly(x, 1)`
In the future, `n` could also be a range.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Currently there are instructions on how to setup jj to work with GitHub,
but not Gerrit, which seems to be very popular with the jj community.
Add a gerrit.md file to help users discover the jj gerrit subcommand.
I have no idea if we can change the default, but maybe we can conditionally
disable the same-change rule to get rid of hacks in squash_commits(), etc.?
resolve_file_executable() doesn't respect the Store configuration. I'm not sure
if that's the right choice, but it seemed better to accept duplicated change
than falling back to executable=false.
#6369
Adds a new `--when.platforms` condition for including configuration.
This is useful when someone syncs their dotfiles across machines.
The values for `platforms` are defined by `std::env::consts::FAMILY` and
``std::env::consts::OS. Any Unix-family platform can be specified using
the value `"unix"`, or individual operation systems can be chosen with
`"linux"`, `"macos"`, or `"windows"`.
Example:
```toml
ui.pager = ["less", "-FRX"]
[[--scope]]
--when.platforms = ["windows"]
ui.pager = ["C:/Program Files/Git/usr/bin/less.exe", "-FRX"]
```
This option affects emptiness of commits, which means indexed changed files can
become stale on configuration change. This problem can also be said for changes
in the diff algorithms, so I don't think we need a logic to invalidate index on
config change.
I have this patch for months, and it seems working good at least for Rust
sources.
Closes#17
This commit includes a jj recipe for the Git command table that is
approximately equivalent to Git's checkout command, which can be used to
examine source code at named revision or branch. This is indispensible
for learn-by-doing types who are curious how to remap Git usage back
onto jj with minimal effort.
As suggested by @PhilipMetzger
The word "grey" is whitelisted because
- we have a contributor of that name
- we use a library that uses "Grey" as a member of an enum
- I refuse to believe "grey" is not US English
The pico text editor is effectively absent from the majority of Linux
distributions, having been replaced with nano by virtually all of them.
Some distros have symlinks for `pico` that point to `nano`, but not all
of them. Using nano as the fallback option has a much lower chance of
failure than pico.
Co-authored-by: Remo Senekowitsch <remo@buenzli.dev>
This adds a command that automatically bisects a range of commits
using a specified command. By not having the interactive kind
(e.g. `jj bisect good/bad/skip/reset`), we avoid - for now at least -
having to decide where to store the state. The user can still achieve
interactive bisection by passing their shell as the bisection command.
Closes#2987.
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>
This is a basic implementation of the same string pattern system as in
the revset language. It's currently only used for `string.matches`, so
you can now do:
```
"foo".matches(regex:'[a-f]o+')
```
In the future this could be added to more string functions (and e.g.
the ability to parse things out of strings could be added).
CC: https://github.com/jj-vcs/jj/issues/6893
Now that https://github.com/jj-vcs/jj/pull/7275 has merged it's worth
mentioning that simple fetch refspecs will (now) be respected when other
branches are otherwise not specified on the CLI
Tombi is an LSP that complains about the "$schema" key, because it
itself is not actually part of our schema. Taplo is another LSP that
can read this comment directive. Using a comment seems generally more
appropriate. Syntax highlighting makes comments usually less visible,
indicating that the directive is not actually part of the configuration
data.
After a change has been accidentally modified, the user may want to
recover the original revision with the same commit ID if it was pushed
to a remote, not just restore the original contents.
Instead of using `jj restore` to restore contents, recommend using `jj
new <PREVIOUS_ID>` to unhide the original commit. This strategy works
whether or not the user cares about the original commit ID.
This is the natural counterpart of `jj undo`. Adding `jj redo` closes
the last gap in functionality to the "undo" features of typical GUI
applications. This is much more intuitive to new users and useful than
the previous undo semantics. (Which are preserved as `jj op revert`.)
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
We could instead implement serde::Serialize wrapper manually, but it would be
tedious to process recursive data structure. Let's just rely on the toml crate.
The cost of conversion wouldn't matter.
New users (especially ones unfamiliar with CLI programs) intuitively
expect `jj undo` to work the same way the "undo" functionality of
typical GUI applications do. That means, running `jj undo` multiple
times should restore progressively older states of the repository
one-by-one.
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
This patch doesn't add builtin_evolog_redacted template because I'm not sure if
we want to collect evolution log for debugging purpose. The redacted template
can be added later if needed.
I don't have a strong feeling whether we should add "entry.commit() -> Commit"
method or forward method calls to the Commit object, but this patch implements
the former because:
a. evolution_entry.diff() should return inter diff, whereas commit.diff()
doesn't.
b. auto-labeling works if self.commit() is an explicit method call.
c. the implementation and documentation can be simple.
Tests will be added by the next patch.
This commit clarifies the order in which `trunk()` is resolved following
commit 5fedd36 (git init: prefer `upstream` over `origin` for `trunk()`
alias).
This allows checking whether "any" or "all" elements in a list satisfy a given
predicate, similar to Python's native `any()` and `all()` functions, but
instead as list methods that take lambda predicates.
These new methods follow the same pattern as existing `filter` and `map`
operations, i.e. taking a lambda that receives each item and must return a
boolean.
This paves the way for the semantics of `jj undo` and `jj op revert` to
evolve independently. `jj op revert` is going to stay the low-level
command to apply the inverse of any operation. The new name is
consistent with `jj revert`, which applies the inverse of a commit.
`jj undo` on the other hand is planned to become a higher-level command,
which is more similar to, say, Ctrl+Z in typical GUI applications.
Running `jj undo` repeatedly will revert progressively older operations,
allowing the user to walk backwards in time. At the same time, `jj undo`
will lose the abilitly to revert arbitrary operations, to keep its
semantics simple and intuitive.
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
Most users colocate all of their repositories or none of them. A config
option is more convenient in that situation.
There are also plans to make colocated repos the default. This change
paves the way to flip the default easily.
Closes#2507.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
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`).
On Windows, spawning a child process finds the command relative to the
parent's working directory. If a command is specified as
`["path/inside/repo/tool.exe"]`, then tool won't be found if `jj fix` is
run from a subdirectory of the workspace.
There doesn't seem to be a good way to change this behavior, nor does it
seem easy to convert `program` into an absolute path because
`["tool.exe"]` could refer either to a file on the PATH or a file
committed at the root of the repository.
So, we add a new variable `$root` that can be used in this situation.
Workspace-relative tools on Windows should be defined using this
variable:
```toml
# Tools on the PATH
command = ["tool.exe"]
# Workspace-relative tools
command = ["$root/tool.exe"]
command = ["$root/nested/dir/tool.exe"]
```
On Unix, the command is found relative to the working directory of the
child process, so this isn't an issue.
Fixes#7144
I was initially planning to try adding an `nth` keyword argument to
`parents()` instead of adding `first_parent()`, and I noticed that based
on the current style, it would have been shown as one of the following
in the revset documentation:
* `parents(x[, depth[, [nth=]index]])`
* `parents(x[, depth][, [nth=]index])`
These both seem difficult to read to me, so I'm proposing changing the
style to something more like this:
* `parents(x, [depth], [[nth=]index])`
I also added a brief section explaining the syntax in case it isn't
immediately obvious what the square brackets mean.
