`jj bisect run --command` splits the argument on spaces, so
e.g. `--command 'cargo test'` will run `cargo` with `test` as
argument. It is hard to pass more complex commands to because we don't
parse e.g. quotes as the shell would (and we wouldn't match the user's
preferred shell even if we did).
This patch deprecates the `--command` argument in favor of positional
arguments, so the user can do things like this:
```
jj bisect run --range ..main -- bash -c 'jj duplicate -r xyz -B @ && cargo test'
```
That will run the tests with the `xyz` change applied.
- Added support for workspace-specific configuration using `jj config` commands.
- Introduced `--workspace` option to `jj config edit`, `jj config set`, and `jj config unset`.
- Workspace configuration file is stored in `.jj/workspace-config.toml` per workspace.
- Simplified workspace path handling logic.
- Updated documentation and test snapshots to reflect new behavior.
This improves flexibility for users working across multiple workspaces.
Co-authored-by: Eidolon <furyhunter600@gmail.com>
Co-authored-by: ase <adam@sandbergericsson.se>
This is mostly a revert of dd73b5ab7d. It closes#5374, as feedback on
the issue has shown that many longtime and new users dislike it. Martin
himself also mentioned that he wants to walk back this deprecation.
Co-authored-by: Remo Senekowitsch <remo@buenzli.dev>
This implements the most basic workflow for submitting changes to Gerrit,
through a verb called 'upload'. This verb is chosen to match the gerrit
documentation (https://gerrit-documentation.storage.googleapis.com/Documentation/3.12.1/user-upload.html).
Given a list of revsets (specified by multiple `-r` options), this will parse
the footers of every commit, collect them, insert a `Change-Id` based off the jj change-id (if one doesn't already exist), and then push them into the given remote.
It will then abandon the transaction, thus ensuring that gerrit change-IDs do not appear in jj.
Because the argument is a revset, you may submit entire trees of changes at
once, including multiple trees of independent changes, e.g.
jj gerrit upload -r foo:: -r baz::
Signed-off-by: Austin Seipp <aseipp@pobox.com>
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.
There were some concerns that `touch` only makes sense if you're
familiar with the Unix `touch` command. I think that's a fair
concern. I did not hear any objections to renaming the command. If
we're going to do it, we should do it now, so it doesn't ever get
released under the old name.
I considered adding more details, but ultimately decided to err on the
side of brevity. We could later write a short doc detailing the behavior
(see the comments in the source) and point the CLI docs to it.
For now, I tried to explain the smallest mental model the users should
have in mind to feel comfortable with these commands.
Since `jj redo` is the command that really makes the notion of an "undo
stack" tick, I only mentioned that notion in there.
Follows up on #7293 and #7277
For me, the trickiest part of figuring out how to use the new options
was to realize that I should assume `--from @` when using them, and
that I should not think of `-r` at all.
We still need more docs, but I think this would be a helpful
pointer for experienced users wanting to experiment with this.
Follows up on 1e58ca2253https://github.com/jj-vcs/jj/pull/7162 introduced some interesting and
useful functionality, but I feel like we should not commit to the exact
UI it sets up. The current UI is great for experimenting with this
functionality, and I don't have an immediate idea for what exactly would
be better. I'm hoping that with time and some experience
using it, we'll come up with something. See
https://github.com/jj-vcs/jj/pull/7162#issuecomment-3212555183 for more
details on this thought.
The main goal is to point new users of `squash` to the old UI, both
because I think it's currently more intuitive for new people, and also
so that they don't feel like obligated to learn the new UI, and so that
they don't get paralyzed by choice.
Another, more minor, reason to mark this as "experimental" is that it's
currently under-documented.
Since the situation is a bit confusing, and following Martin's
suggestion, I also removed these from the changelog for now.
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
This changes the behavior of git fetch to respect the fetch refspecs
configured on the remote. This is handy for projects which use
customized fetch refspecs (e.g. only fetch certain patterns, but not all
branches) but without having to remember and repeat all the patterns by
hand on the CLI
Fixes#5323
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.
Add `--tracked` flag to `jj git fetch` that fetches only tracked bookmarks
from the specified remote(s). This is symmetrical with the existing `jj git
push --tracked` functionality and is useful in large repositories where
fetching all bookmarks is slow, and manually specifying each tracked bookmark
is cumbersome.
Conflicts with `--branch` to avoid confusion. When no tracked bookmarks are
found for a remote, a warning is displayed and the remote is skipped.
Resolves#7209
For example, with a commit tree like this one:
@ kkrvspxk (empty) (no description set)
○ lpllnppl file4
│ A file4
○ xynqvmyt file3
│ A file3
○ wkrztqwl file2
│ A file2
○ mzuowqnz file1
│ A file1
♦ zzzzzzzz root()
we can jj squash -f x:: -d m to squash xynqvmyt and all its descendant
as a new commit onto mzuowqnz.
@ youptqqn (empty) (no description set)
○ wkrztqwl file2
│ A file2
│ ○ vsonsouy file3 file4
├─╯ A file3
│ A file4
○ mzuowqnz file1
│ A file1
♦ zzzzzzzz root()
On the implementation side, I've chosen to prepare the destination
commit before hand, and keep the squash algorithm mostly unmodified.
`jj undo` is planned to become a higher-level command that progressively
undoes more operations when executed repeatedly (in a strict order).
This will be separate from the lower-level semantics of `jj op revert`,
which reverts arbitrary operations on top of the current one. The
semantics of the new, high-level `jj undo` won't make sense when
combined with specifying a specific operation to undo. Thus, start the
lengthy deprecation period right now.
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
By default, `git clone` will fetch all tags (same as `git clone
--tags`), but since we perform a clone by creating a remote first then
fetching it, we have to be a little smarter and keep track of when we're
doing a clone so that we ensure all tags are fetched.
`git clone --no-tags` will skip fetching tags at all, and so this is
also the now the behavior of `jj git clone --fetch-tags none`
Closes#4682
Add `-T/--template` flag to `jj op show` to allow custom formatting of
output, matching the functionality available in `jj op log`.
Also add `--no-patch` flag to suppress the diff.
`templates.op_log` remains available as a config setting, used as a fallback
when `-T/--template` is not specified.
Resolves#6980
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
The short description for `--reset-author` previously made no mention of
updating the author timestamp as well as the author name and email. This
change adds verbiage to clarify that.
While the generated markdown is correct, it was being rendered as a
single list. This might be caused by the `mdx_breakless_lists` plugin
because the issue doesn't happen when the plugin isn't used (that is,
when the list actually has linebreaks above it).
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 primary use case is to insert header/separator when printing multiple file
entries.
"jj file show" accepts the same template argument as "jj file list", and file
content is not included in the template. This is basically the same as the
relation between "jj show" and "jj log".
Closes#7181
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
