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
Since divergent/conflicted symbols no longer resolve to multiple revisions, it's
less scary to allow "large" revsets than before.
The config doc is removed because it's largely duplicated from the revsets doc,
and the config key will be removed.
#6016
In this implementation, we assume that predecessor commits created by old jj are
reachable from at least one of the historical views. However, there are a couple
of commands which create transitive predecessors. For example, "jj squash" into
grandparent will rebase a rewritten source, so the pre-rebase source commit
won't be visible to any views. To work around the problem, all immediate
predecessors of historically visible commits are also preserved.
Note that this change should be considered forward-incompatible change. The
stored commits may have unreachable predecessors once we run "jj op abandon &&
jj util gc".
WalkPredecessors::flush_commits() doesn't need to guard against unreachable
commits. I was wondering whether values (or old ids) of op.commit_predecessors
map should be preserved, and I decided to keep both keys and values. It's nice
that we can get rid of index.has_id() calls when we drop support for legacy
commit.predecessors.
There's no technical reason to restrict the starting revisions to a single
commit, and it will be nice that we can see evolution history of duplicated,
split, or divergent commits.
The optional arguments for each shell were deprecated in #2945 and v0.19.0.
The `shell` argument is now required, and Bash completions are no longer generated by
default if `jj util completion` is run without any arguments.
This serves a similar purpose to Git's patch ID mechanism, however it is
slightly different in that it only compares commits which have the same
change ID as each other (divergent changes), and it does a full
comparison of the commits to see if they would have identical trees if
rebased onto the same parents. Since most changes aren't divergent, I
believe this should have a negligible performance cost in most cases.
I think skipping these commits by default makes sense for `jj rebase`,
since usually this will be a helpful behavior for the user. With this
behavior, a safe first step when encountering divergent changes would be
to rebase one branch on top of the other, since that will abandon any
divergent changes that have identical contents to existing commits,
leaving behind any non-trivial divergent changes for the user to resolve
manually.
It isn't necessary to include shebangs in scripts passed into
`util exec` since you're already explicitly calling out the shell you'd
like to use. This change removes shebangs from examples for `util exec`
and adds a note below calling this out.
This is just for completeness. I don't think this is practically useful, but the
:<format> syntax should work in both config files and command arguments.
