It's odd that cmd_help() returns an error for valid arguments. Let's look up the
target command explicitly. We still need to do app.try_get_matches_from_mut() to
initialize clap::Command internals, though.
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.
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.
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.
This means `f ()`, `x . f()`, etc. are now allowed. Before, `x\n.f()` was syntax
error, which seemed unintuitive in multi-line expression.
This also means that whitespace around alias declaration is ignored.
tempalte-aliases.' foo ' is identical to tempalte-aliases.foo.
https://pest.rs/book/grammars/syntax.html#implicit-whitespaceCloses#7378
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.
The top-level `immutable` and `conflict` labels we add to commits in
the node templates are also useful in the text part. For example, we
may want to color change ids for immutable commits differently (we do
that at Google). I also added a `mutable` label, to make it easier to
define colors for mutable commits without having to define the color
for all commits and then overriding it for immutable commits.
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
I sometimes want to see how commit description is evolved.
This patch adds a separate loop for diff of commit descriptions. This should be
okay since DiffRenderer wouldn't have more than one "long" formats.
Alternatively, we could add a fake TreeDiff entry so the commit description
would be represented as a file in all diff formats. I have no idea which would
provide better UX, so I chose the simpler one.
Closes#7202
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
The operation timestamp is often very close to the committer timestamp, so I
don't think it's useful in evolog. I also removed "root()" as it wouldn't be
useful either, and the root operation should have no evolved commits.
I got annoyed by the checkout function and tried to compress the code a bit,
and I think the result is much nicer. I'm not certain that a closure is the
right solution here, but I think it becomes easier to reason about the two
temp filenames that get generated.
I initially changed `Option<DiffSide>` to a bool, but found an enum more
meaningful and more likely to be flexible in the future.
I also moved the instruction writing to its own function. This makes the main
`DiffEditWorkingCopies::check_out()` function much nicer.
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
`jj undo` and `jj op revert` used to be aliases. Now that their
semantics are planned to diverge, we need to think about which of the
existing tests belongs to which of the commands. Since `jj op revert`
will keep the current low-level semantics, all of the tests naturally
belong to it. `jj undo` will incrementally grow a new set of tests
together with its new, higher-level functionality. Some tests are
duplicated, in anticipation that they will be meaningful for `jj undo`
as well.
The moved tests are left as-is, except for any references to "undo" are
replaced by "revert" and invocations of `jj undo` are replaced by
invocations of `jj op revert`.
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
When both `origin` and `upstream` are present, prefer `upstream` over `origin`
as the default remote for the `trunk()` alias.
This allows developers working on forks to have `trunk()` automatically point
to the `main` branch of the upstream repository rather than their fork's
origin. This is common when using the `gh` CLI to set up repositories.
Resolves#7228
