Previously, attempting to modify an immutable commit only showed the
ID of the commit being modified, which wasn't very helpful when trying
to figure out which immutable commit is being modified at a quick
glance.
This commit prints the commit summary as a hint to make it simpler for
the user to see what the immutable commit is without having to run
`jj show <commit-id>`.
Maybe we can add comparison of ids, commits, etc., but I don't have a practical
use case right now. If we add lt/gt, it might make sense to implement them on
Timestamp type.
I also changed lhs.and_then(..) to (lhs, rhs).map(..) since we don't need
short-circuiting behavior here.
Visible aliases interfere with shell completion, at least in Fish. For
example, `jj des<tab>` stops as `jj desc` without adding a space
afterwards, which make me stop for a second and wonder if I need to
add more letters. They also show up in the auto-complete menu.
I added "[aliases: <name>]" as part of the first line of the help text
so the `jj help` output still looks the same.
The recover commit we create in some cases (when an operation has been
lost) doesn't currently have a description. That makes it easy to miss
that it's special.
Both user and programmatic expressions use the same .evaluate() function now.
optimize() is applied globally after symbol resolution. The order shouldn't
matter, but it might be nicer because union of commit refs could be rewritten
to a single Commits(Vec<CommitId>) node.
This helps add library API that takes resolved revset expressions. For example,
"jj absorb" will first compute annotation within a user-specified ancestor range
such as "mutable()". Because the range expression may contain symbols, it should
be resolved by caller.
There are two ideas to check resolution state at compile time:
<https://github.com/martinvonz/jj/pull/4374>
a. add RevsetExpressionWrapper<PhantomState> and guarantee inner tree
consistency at public API boundary
b. parameterize RevsetExpression variant types in a way that invalid variants
can never be constructed
(a) is nice if we want to combine "resolved" and "unresolved" expressions. The
inner expression types are the same, so we can just calculate new state as
Resolved & Unresolved = Unresolved. (b) is stricter as the compiler can
guarantee invariants. This patch implements (b) because there are no existing
callers who need to construct "resolved" expression and convert it to "user"
expression.
.evaluate_programmatic() now requires that the expression is resolved.
I originally considered adding deny-list-based implementation, but the Windows
compatibility rules are super confusing and I don't have a machine to find out
possible aliases. This patch instead adds directory equivalence tests.
In order to test file entity equivalence, we first need to create a file or
directory of the requested name. It's harmless to create an empty .jj or .git
directory, but materializing .git file or symlink can temporarily set up RCE
situation. That's why new empty file is created to test the path validity. We
might want to add some optimization for safe names (e.g. ASCII, not contain
"git" or "jj", not contain "~", etc.)
That being said, I'm not pretty sure if .git/.jj in sub directory must be
checked. It's not safe to cd into the directory and run "jj", but the same
thing can be said to other tools such as "cargo". Perhaps, our minimum
requirement is to protect our metadata (= the root .jj and .git) directories.
Despite the crate name (and internal use of std::fs::File),
same_file::is_same_file() can test equivalence of directories. This is
documented and tested, so I've removed my custom implementation, which was
slightly simpler but lacks Windows support.
I'm going to add "checked" version of to_fs_path(), but all callers can't be
migrated to it. For example, an error message should be produced even if the
path is malformed.
This patch also adds error variants to propagate InvalidRepoPathError. They
don't use ::Other { .. } so the errors can be distinguished in tests.
I think `cargo publish` will currently fail because of the
`include_str!()` in `cli/src/commands/help.rs` pointing to
`../../../docs/`, i.e. outside of the crate directory. This patch
attempts to fix that creating a `cli/docs` symlink to `docs` and makes
the `include_str!` use that symlink. I hope the symlink will be
resolved at `cargo publish` time so it also works in the published
crate.
Because symlinks don't work well on Windows, I updated `cli/build.rs`
to include the original path (the one pointing outside the crate) if
`cli/docs` is not a symlink, so the regular build still should work on
Windows (but `cargo publish` won't).
Thanks to Yuya for proposing this solution.
This one is the last caller of .evaluate_programmatic() who needs symbol
resolution. Let's switch to the user revset machinery and resolve "@" as a
symbol. If this expression didn't contain "remote=<remote>" parameter, the
default would be expressed as a string RevisionArg::from("...").
We will need this in the `jj git sync` command to perform a fetch that behaves
the same as the `jj git fetch` command.
* Refactor out `git_fetch` and move it to `git_util.rs`
* Also move `warn_if_branches_not_found`. It is only used by `git_fetch`
* Move `map_git_error` to `git_util.rs` and update other call sites to import correctly.
* Update using statements as needed.
All tests still pass as this is a noop.
Part of: #1039
The problem is that author names are variable-length by nature, and format_*()
can be customized in that way. Commit ids are redundant in most cases where
commits aren't diverged.
We could add some format_short_fixed_length_*() hook points, but it would
probably be easier to just customize the annotation template at all.
For the same reason as the previous patch. It's nice if root() is considered
a "resolved" expression. With this change, most of the evaluate_programmatic()
callers won't have to do symbol resolution at all.
It would be nice to not need to go the documentation website. This aims
to solve that by introducing the concept of keyword to the help
command.
Basically, keywords are things that we want to add help messages to,
but they don't necessarily have an associated subcommand.
For now we only have two keywords:
- `revsets`: Shows the docs for revsets
- `tutorial`: Shows the tutorial that is on the documentation
You get the keyword content by tipping `jj help --keyword revsets` or
`jj help -k revsets`.
You can also list the available keywords with `jj help --help`.
It would be nice to have all the documentation on the keywords, maybe
a next commit could do it.
We had documented that we support `git.auto-local-bookmark` but we
don't. The documentation has been incorrect since d9c68e08b1. This
patch fixes it by adding support for `git.auto-local-bookmark` with
fallback to the old/current `git.auto-local-branch`.
.
Allow unsetting config values similar to `git config unset`.
```bash
$ jj config set --user some-key some-val
$ jj config get some-key
some-val
$ jj config unset --user some-key
$ jj config get some-key
Config error: configuration property "some-key" not found
For help, see https://martinvonz.github.io/jj/latest/config/.
```
Unsetting a key, which is part of a table, might leave that table empty.
For now we do not delete such empty tables, as there may be cases where
an empty table is semantically meaningful
(https://github.com/martinvonz/jj/issues/4458#issuecomment-2407109269).
For example:
```toml
[table]
key = "value"
[another-table]
key = "value"
```
Running `jj config unset --user table.key` will leave us with `table`
being empty:
```toml
[table]
[another-table]
key = "value"
```
We might want to calculate (commit_id, range) pairs of consecutive lines in
order to "absorb" changes, for example.
This should also be cheaper since Vec<u8> doesn't have to be allocated per line.
For a new user, it is not clear how to view the full commit
message/description of a change with `jj log`.
This fix this, add a new template alias
`builtin_log_compact_full_description` to display the commit like
`builtin_log_compact` does but with a full description.
The user can set it to true on the config like this:
```
templates.log = builtin_log_compact_full_description
```
Fixes: #3688