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.
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
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/
```
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
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
This makes the `test_version` test failure when run at a merge commit
less confusing. The test could be fixed, but I'm not sure it's worth it,
as we probably don't want to release a version of `jj` compiled at a
merge commit.
Now, if `jj` is compiled at a merge commit, this would print:
```
$ jj --version
jj 0.31.0-fb10a78cb359d52c0eda518a42ab07f117909004-ff9c9d0d8b4e929843eb683709fc1717645796df-99e035c5054e71906d7293ed98b542a9055057ef
```
Admittedly, this is a bit of a quick hack, but I've been confused by
`jj --version` output when compiled at a merge commit enough times
to want it.
Prior art: https://github.com/jj-vcs/jj/pull/6311 and
https://github.com/jj-vcs/jj/pull/4033 both pick one commit id hash
to print. I think I prefer printing all of them, even if it will fail
tests at a merge commit. After this commit, the failure will at least
be easy to understand.
However, if we prefer to merge one of the others, I'm OK with that too.
It's surprising that a symbol expression may be resolved to multiple revisions,
and that's one of the reason we require all: modifier in some places. Let's make
a symbol resolution fail in that case so we can deprecate the all: syntax.
The new error hints are a bit less informative, but I don't want to implement
ad-hoc formatting for resolve_some_revsets_default_single(). The user will have
to review the graph anyway in order to resolve divergence/conflicts.
Closes#5632
I often use the following command, sometimes in a loop over different repos.
It's annoying when it prints several lines of warnings. One line should
be enough.
```sh
jj git fetch && jj git fetch --remote upstream --branch main --branch master \
--branch 'glob:gh-readonly-queue*' --branch 'glob:ig/*'
```
For most callers, the special sorting of directories before paths for
directory->file transitions is not needed. This patch changes
`diff_stream()` to not do that, and instead adds a new method
specifically for that behavior. Only `local_working_copy` uses it.
In this implementation, we assume that predecessor commits created by old jj are
reachable from at least one of the historical views. However, there are a couple
of commands which create transitive predecessors. For example, "jj squash" into
grandparent will rebase a rewritten source, so the pre-rebase source commit
won't be visible to any views. To work around the problem, all immediate
predecessors of historically visible commits are also preserved.
Note that this change should be considered forward-incompatible change. The
stored commits may have unreachable predecessors once we run "jj op abandon &&
jj util gc".
WalkPredecessors::flush_commits() doesn't need to guard against unreachable
commits. I was wondering whether values (or old ids) of op.commit_predecessors
map should be preserved, and I decided to keep both keys and values. It's nice
that we can get rid of index.has_id() calls when we drop support for legacy
commit.predecessors.
Since we have "reverse hex" functions, it's easy to implement the same set of
functions for "forward hex". I believe our implementation is slower than
highly-optimized versions provided by e.g. faster-hex, but we don't use hex
encoding/decoding where the performance matters.
Since the goal of this pseudo type is to get a String value, it can be called a
ToString or Stringify. I chose the latter because Stringify sounds similar to
Serialize (verb), and I don't want to rename the internal functions to
.try_into_to_string().
https://github.com/jj-vcs/jj/pull/6840#discussion_r2173076763
Basically, these functions work in the same way as bookmarks()/tags(). They
restrict the namespace to search the specified symbol, and unmatched symbol
isn't an error. One major difference is that ambiguous prefix triggers an error.
That's because ambiguous prefix should logically select all matching entries,
whereas the underlying functions don't provide this behavior. It's also unclear
whether we would want to get all matching commits by commit_id(prefix:'').
#5632
There aren't many callers, and it was inconsistent that some callers didn't
attach alias traces to diagnostic messages.
The stripped-down expect_<construct>() functions also attempt to unwrap aliases
for consistency reasons. This is redundant, but should be cheap. If there were
callers who don't need to reinterpret a string literal, they wouldn't have to
use catch_aliases() block at their call sites.
This way it becomes possible, when squashing multiple commits, to specify
from which commit we keep the change-id, without needing to provide
multiple --from parameters.
For example, for a set of commits from x to z, with y somewhere in the
middle, before we had to run
jj squash --from x::y- --from y+::z -into y
to squash x::z into y. Now we can
jj squash --from x::z -into y
Squashing into the same change as the source becomes a no-op.
On the implementation side, we just make sure the destination commit is
not in the source commits.
