Also resolves one TODO made possible by the new MSRV
Most of this was done by enabling the lint forbidding `allow` directives
using `cargo cranky`, running `cargo cranky --workspace
--all-featuers --fix`, and fixing up the result.
This makes the graph compact. Short change ids are usually printed as a part
of commit summary. The --no-graph output is a bit harder to parse, but we can
still discriminate entries by change ids.
There are some experiments to try and compile `jj` to WebAssembly, so that we
might be able to do things like interactive web tutorials. One step for that
is making `git` support in `jj-cli` optional, because we can stub it out for
something more appropriate and it's otherwise a lot of porting annoyance for
both gitoxide and libgit2.
(On top of that, it might be a useful build configuration for other experiments
of mine where removing the need for the large libgit2 depchain is useful.)
As part of this, we need to mark `jj-lib` as having `default-features = false`
in the workspace dependency configuration; otherwise, the default behavior
for Cargo is to compile with all its default features, i.e. with git support
enabled, ignoring the `jj-cli` features clauses.
Other than that, it is fairly straightforward junk; it largely just sprinkles
some `#[cfg]` around liberally in order to make things work. It also adjusts the
CI pipeline so this is tested there, too, so we can progressively clean it up.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
There should be no difference, but it's more consistent that all workspace/repo
commands use workspace_command.settings(), etc. than command.settings().
Adds a new "ui.conflict-marker-style" config option. The "diff" option
is the default jj-style conflict markers with a snapshot and a series of
diffs to apply to the snapshot. New conflict marker style options will
be added in later commits.
The majority of the changes in this commit are from passing the config
option down to the code that materializes the conflicts.
Example of "diff" conflict markers:
```
<<<<<<< Conflict 1 of 1
+++++++ Contents of side #1
fn example(word: String) {
println!("word is {word}");
%%%%%%% Changes from base to side #2
-fn example(w: String) {
+fn example(w: &str) {
println!("word is {w}");
>>>>>>> Conflict 1 of 1 ends
}
```
.get_table() isn't implemented because it isn't cheap to build a HashMap,
and a table of an abstract Value type wouldn't be useful. Maybe we'll
instead provide an iterator of table keys.
.config() is renamed to .raw_config() to break existing callers.
Custom backends may rely on networking or other unreliable implementations to support revsets, this change allows them to return errors cleanly instead of panicking.
For simplicity, only the public-facing Revset and RevsetGraph types are changed in this commit; the internal revset engine remains mostly unchanged and error-free since it cannot generally produce errors.
Added colons to make it seem less like an English sentence, see
https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776
I believe printing both the start and end times is excessive for a
summary. For now, I have it print just the start time for consistency.
I intend to change it to print the ending time later.
I was a bit torn on whether to use `format_timestamp(self.time().start())`
or `self.time().start().ago()`. The latter looks better, but is less
configurable and worse for dates long ago. In the future, we could add a
`format_op_summary_timestamp` function and/or a template function that
uses `.ago()` for recent dates and absolute dates for old dates.
This ensures that the data printed through the raw stream is colorized if the
formatter already had color labels, and if the raw data doesn't reset the
surrounding color. This would only matter in templates containing
label(.., raw_escape_sequence() ..) expression.
Fixes#4631
This adds `raw_escape_sequence(...)` support for things that use
FormatRecorder like wrapped text / `fill(...)` / `indent(...)`.
Change-Id: Id00000004248b10feb2acd54d90115b783fac0ff
Most collection references implement `.into_iter()` or its mutable version,
so it is possible to iterate over the elements without using an explicit
method to do so.
Deprecation warnings will be printed there. auto_tracking_matcher(ui) could
be cached, but there aren't many callers right now, so it should be okay to
parse and emit warnings for each invocation. Other than that, the changes are
straightforward.
Multiple graphs will be nested in "op log" output, and things would be messy if
we had to calculate graph widths lazily. Let's simply make LogContentFormat
track the current available width no matter if ui.log-word-wrap is off.
Jujutsu's branches do not behave like Git branches, which is a major
hurdle for people adopting it from Git. They rather behave like
Mercurial's (hg) bookmarks.
We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord,
where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were
reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name
the current mechanism. This may be hard break for current `jj branch` users, but it will immensly
help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]`
config option is currently left alone, to force not another large config update for
users, since the last time this happened was when `jj log -T show` was removed, which immediately
resulted in breaking users and introduced soft deprecations.
This name change will also make it easier to introduce Topics (#3402) as _topological branches_
with a easier model.
This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from
me being lazy or thankfully pointed out by reviewers.
I'll use a similar setup in "op log", but for each log entry. We might want to
extract some parts to helper function, but I don't have a good idea right now.
CommandHelper::operation_template_extensions() is removed because it's unlikely
to parse operation template without loading a workspace.
We had both `repo()` and `mut_repo()` on `Transaction` and I think it
was easy to get confused and think that the former returned a
`&ReadonlyRepo` but both of them actually return a reference to
`MutableRepo` (the latter obviously returns a mutable reference). I
hope that renaming to the more idiomatic `repo_mut()` will help
clarify.
We could instead have renamed them to `mut_repo()` and
`mut_repo_mut()` but that seemed unnecessarily long. It would better
match the `mut_repo` variables we typically use, though.
I'm thinking of adding an option to embed operation diffs in "op log", and
"op log" shouldn't fail at the root operation. Let's make "op diff"/"show"
also work for consistency.
Suppose a squash node in obslog is analogous to a merge in revisions log, it
makes sense to show diffs from auto-merge (or auto-squash) parents. This
basically means a non-partial squash node no longer shows diffs.
This also fixes missing diffs at the root predecessors if there were.
As the doc comment states, this function only supports change of "a single
added and removed commit", "only a single added", or "single removed commit."
It doesn't make sense to show diffs from the parent commit ignoring multiple
removed commits for example.
The width parameter is mandatory so it wouldn't fall back to ui.term_width() by
mistake. The API is getting messy and we might want to extract some parameters
to separate struct.
Fixes#4158
It's wrong to deduce loaded_at_head from command-line arguments if the repo was
loaded at an arbitrary operation. Instead, the caller should specify whether
the working copy state is synchronized with the repo view.
I think .for_loaded_repo(ui, workspace, repo, true) would be bad for
readability, so I added separate functions. I'm not happy with the name
.for_temporary_repo(), but it seems okay for the current call sites.
