This partially addresses #4549 together with the parent commits. A further
step would be to make it clearer to the users why a tool is disabled. For
now, this information is added to the comments of `merge-tools.toml`
Not setting `diff-args` is equivalent to `diff-args=["$left",
"$right"]`, which I also documented here.
I couldn't decide whether the new error should be part of
`DiffRenderError`, `DiffGenerateError`, or `MergeToolError`. Since the
treatment of diff formatters is already very different from other merge
tools, I just made it a CommandError for now.
They are not the most useful diff formatters, but they function, so
I thought it's better than making this an error in the following commits.
I also tried to clarify the comments a bit.
`Store::tree_builder()` returns a `TreeBuilder`. Almost all callers
should be using the `MergedTreeBuilder` these days. This patch
therefore removes `tree_builder()` to reduce the risk of accidentally
using it.
Add a parents() method for `Operation` template objects, copied from the
implementation for `Commit`s.
The test case added in test_operations.rs was heavily inspired by
test_commit_templates.rs:test_log_parents().
Fixes#6979
This was requested by @lilyball on Discord. I still think we should create a blog longterm
so we can announce stuff and run surveys, but this small step won't block it.
Previously, the computation for the available display width
included a padding constant, but this value was then used as
an upper bound for the width of the bar. This meant the bar
would never fill the available screen width.
This change makes status collapse directories which don't contain any
tracked files into one line so that large untracked directories don't
clutter up the status with loads of files.
For example for a tree like this:
```
T src/main.rs
U src/lib.rs
U tmp/a.txt
U tmp/b.txt
```
Previously the status would display these untracked paths:
```
? src/lib.rs
? tmp/a.txt
? tmp/b.txt
```
With this change it now looks like this:
```
? src/lib.rs
? tmp/
```
In 1b1edc7a90, I missed the importance of this comment:
```
// Whenever we add an entry to `self.pending_trees`, we also add an Ok() entry
// to `self.items`.
```
The `self.items` entry was there to make sure that we wait for the
pending tree to be polled to completion, thus resulting in its entries
getting added to `self.items`. After my commit, we no longer always
add an entry to `items`, which meant that we can end up emitting
entries from a parent tree before entries in a child tree, such as
`foo/baz` before `foo/bar/qux` even though `baz` comes after `bar`.
This patch fixes the bug by instead checking in `self.pending_trees`
that there are no directories that we need to emit first. Thanks to
@yuja for the suggestion to do it this way instead.
The next patch will update the tests to catch regressions.
The `TestBackend` methods currently return their data immediately (on
the first poll), which means that if multiple futures are created and
then they're polled "concurrently", they will always return their data
in the order they're being polled. That leads to poor testing of
algortihms that poll futures concurrently, such as `TreeDiffStream`.
This patch makes `TestBackend` spawn async work to run in a tokio
runtime instead. That's enough to show a bug I introduced with my
recent refactoring of `TreeDiffStream`, except that it's also covered
up by the caching we do in `Store`. I'll fix the bug and update tests
to work around the caching next.
This slows down the jj-lib tests from 2.8 s to 3.1 s. I don't think
that matter much, given that the jj-cli tests takes > 30 s.
I tried to add a small `tokio::time::sleep()` (random up to 5 ms) but
that slowed down the property-based tests of the diff editor very
significantly (took over a minute). Maybe we could have two different
kinds of test backend or maybe make the sleep configurable in some
way. We can improve that later. The async-ness added in this patch is
sufficient for catching the diff-stream bug.
It should genenerally be better to prioritize polling trees in the
order we're going to emit their entries. For example, if we have
pending trees `zzz/` and `dir/aaa/`, it's better to poll the latter
even though we inserted the former first.
This also prepares for fixing a bug related to the order we emit. We
will then want to look up in `pending_trees` by key found in `items`.
Fix tools often emit information on stderr for the user to see. Since
fix tools are run in parallel and stderr is unbuffered, this information
can be jumbled together. This seems to happen especially frequently on
Windows.
This change locks stderr before writing to it so the stderr output from
a tool is written all at once.
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
As we've discussed on Discord, the community would prefer the
community leaders to be people who are actively involved in the
community. Vamsi hasn't been involved lately, and Isaac has offered to
take on the role. Thanks, both!
I don't think the original implementation handles sorting and filtering of the
renamed source paths correctly, so I've added explicit .sort() at the end.
Fixes#6922
If we add changed-files index, MutableIndex::add_commit() will have to update
both MutableIndexSegment of commits and MutableChangedFileIndexSegment or
something. It won't make much sense to add high-level .add_commit() function to
MutableIndexSegment.
We still get many questions about the difference between `..` and
`::`. It turns out we didn't have an example of the typical case of
using `..` to find commits on a feature branch compared to the main
branch. This patch adds such an example.
