I added a function for updating the description on an existing
transaction. That way we can create the transaction earlier. I'll try
to make `--change` and `--branch` not mutually exclusive next.
The idea is that .as_composite() is equivalent to .as_index(), but for the
implementation type. I'm going to add "impl Index for CompositeIndex" to
clean up index references passed to revset engine.
I've added a helper function because the construction of the range expression
is a bit noisy. It could be a Repo method, but I don't want to make it a
default implementation of the trait method.
revset::walk_revs() let the caller handle RevsetEvaluationError since the
evaluation engine may error out even with such a trivial query. For now, most
callers just .unwrap() the error as before.
Since we abuse TOML table syntax to define function aliases, an identical
function alias can be found more than once in the merged config. The merged
config doesn't preserve the definition order, so we need to load aliases
table per layer.
`jj sparse` is a bit different from other commands in that its `jj
sparse --list` is practically a separate command. Let's make it an
actual subcommand for consistency, and so we can more cleanly add
additional flags for `jj sparse list` in the future. I moved all the
other arguments to `jj sparse set`. I'm not sure if `jj sparse set
--reset` would have been better as `jj sparse reset`, but it is
technically just updating the sparse patterns just like the other
arguments (`--clear`, `--add` , `--remove`).
This has several advantages:
* Makes it possible to downcast to non-Git custom backends (might be
useful at Google, but we haven't needed it yet)
* Lets us access more specific functionality on the `GitBackend`,
making it possible to access the `git2::Repository` without
creating a copy of it.
* Removes the dependency on Git from the backend
This adds a config called `revsets.short-prefixes`, which lets the
user specify a revset in which to disambiguate otherwise ambiguous
change/commit ids. It defaults to the value of `revsets.log`.
I made it so you can disable the feature by setting
`revsets.short-prefixes = ""`. I don't like that the default value
(using `revsets.log`) cannot be configured explicitly by the
user. That will be addressed if we decide to merge the `[revsets]` and
`[revset-aliases]` sections some day.
I would like to copy Mercurial's way of abbreviating ids within a
user-configurable revset. We would do it for both commit ids and
change ids. For that feature, we need a place to keep the set of
commits the revset evaluates to. This commit adds a new
`IdPrefixContext` type which will eventually be that place. The new
type has functions for going back and forth between full and
abbreviated ids. I've updated the templater to use it.
I want to store some lazily calculated data associated with a
repo. The data will depend on the user's config, which means it
shouldn't live in the `ReadonlyRepo` itself. We could store it
directly in `WorkspaceCommandHelper` - and I did that at first - but
it's annoying and risky to remember to reset the cached data when we
update the repo instance (which we do when a transaction
finishes). This commit therefore introduces a wrapper type where we
can store it. Having a wrapper also means that we can use `OnceCell`
instead of more manually initializing it with a `RefCell`.
I would eventually want the `SymbolResolver` to be customizable (in
custom `jj` binaries), so we want to make sure we always use the
customized version of it.
I left `RevsetExpression::resolve()` unchanged. I consider that to be
for programmatically created expressions.
I plan to add `revsets.short-prefixes` and `revsets.immutable` soon,
and I think `[revsets]` seems like reasonable place to put them. It
seems consistent with our `[templates]` section. However, it also
suffers from the same problem as that section, which is that the
difference between `[templates]` and `[template-aliases]` is not
clear. We can decide about about templates and revsets later.
There were two issues on my end:
1. `known_hosts` doesn't seem to be recognized
2. SSH Agent is ignored despite running
A workaround for 1. is to set the HOME environment variable on Windows, so I added a hint to suggest this. Ideally we would add a `certificate_check` callback to the remote callbacks, but the git2 crate doesn't expose whether the certificate check already succeeded, which makes it useless for this purpose (as we'd be prompting users to accept a certificate even though that certificate is already known to be valid).
As for 2., I changed the behavior from "check SSH Agent if some env variables exist" to "check SSH Agent and only fail if some env variables exist". On Windows SSH Agent doesn't use these env variables (but trying to communicate with it will still work), so now Windows properly works with SSH Agent.
By setting a higher level by default, we open up to using the other
tracing levels without spamming the user.
I'm not sure if we should set it to ERROR or OFF by default, we let's
try ERROR for now. It shouldn't make any difference since we don't
have any ERROR-level events yet.
On "jj checkout", description of the working-copy commit is empty, and the
working-copy parent provides more information. It might be a bit verbose to
print parent summary on every history rewriting, but I think that's okay.
`workspace_root` is [canonicalized](41a2855b4f/lib/src/workspace.rs (L119)), but `cwd` [isn't](41a2855b4f/src/cli_util.rs (L581)). When [working with relative paths](41a2855b4f/src/cli_util.rs (L749-L760)), this leads to issues in Windows: canonicalized paths start with `\\?\`, whereas non-canonicalized paths do not. Therefore, paths were formatted canonicalized, and commands did not accept non-canonicalized paths:
```
$ jj st
Parent commit: bdb62c9 canonicalize cwd in cli_util.rs
Working copy : 059c104379cd (no description set)
Working copy changes:
A \\?\C:\github.com\71\jj\.vscode\launch.json
$ jj diff .vscode\launch.json
Error: Path ".vscode\launch.json" is not in the repo
$ jj diff \\?\C:\github.com\71\jj\.vscode\launch.json
Added regular file \\?\C:\github.com\71\jj\.vscode\launch.json:
...
```
With this change:
```
$ jj st
Parent commit: bdb62c9 canonicalize cwd in cli_util.rs
Working copy : 059c104379cd (no description set)
Working copy changes:
A .vscode\launch.json
$ jj diff .vscode\launch.json
Added regular file .vscode\launch.json:
...
```
This will make it easily available everywhere so we can get more
detailed information about arguments passed to commands. In
particular, I think it can be useful for displaying different hints
depending on whether the user passed `-r @` or if the `@` revision was
from the defaults.
"jj show" is basically a "log" command with different defaults. We'll need
to consider this kind of stuff if we want to introduce namespace to templates.
Establishing a unique file extension for the temporary files created
via `jj describe` helps to ensure that text editors can recognize the
filetype and alter settings accordingly. This will open the door for
an improved user experience, and allow for setting things like the
appropriate text-width/rulers, syntax highlighting of the diff summary
(see Git's commit tree-sitter grammer [1]), easy toggling of the `JJ:`
comment lines, etc.
I examined the behavior of filetype detection across a number of
common text editors, and the most universally-support mechanism was
to have a unique extension that does not include any periods. Meaning
that namespacing via something like `.jj.txt` instead, won't always be
detected due to inconsistent matching prioritization across editors.
It also makes sense to assume that we may want other Jujutsu-specific
filetypes in the future.
The filename prefix has also been switched to be `editor-` for clarity,
as well as to ease matching a glob-pattern if we ever need to garbage
collect leftover tempfiles. This structure is similar to what Mercurial
and Sapling do as well.
[1] https://github.com/the-mikedavis/tree-sitter-git-commit
This is a convenience optimization to improve the default user
experience, since `jj log` is a frequently run command. Accessing the
help information explicitly still follows normal CLI conventions, and
instructions are displayed appropriately if the user happens to make a
mistake. Discoverability should not be adversely harmed.
Note that this behavior mirrors what Sapling does [2], where `sl` will
display the smartlog by default.
[1] https://github.com/clap-rs/clap/issues/975
[2] https://sapling-scm.com/docs/overview/smartlog
Now we have 4 callers, I concluded this is common enough to add an
extension method. Still I think it's preferred to define config items in
src/config/*.toml if possible. It will catch typo of config keys.
I wasn't quite happy with `jj support` but I couldn't think of
anything better when I moved the commands from `jj debug` in
e2b4d7058d. Thanks to @ilyagr for suggesting `jj util`.
