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/*'
```
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.
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
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.
Computed properties are removed from the serialized data. For example,
tracking ahead/behind count can be calculated by querying commits between
the target and tracking target.
This should produce better results at squash/split operations. Since "op diff"
targets can be flipped, this patch implements basic handling of reversed
predecessors graph. It should also work for sibling operations so long as there
are no multiple greatest common ancestors.
resolve_transitive_edges() takes additional "start" parameter. It might be
useful in order to omit transitive edges in evolution log. Since
walk_predecessors() usually tracks a single commit, it would be wasteful to
build a fully-resolved predecessors graph.
When experimenting on hidden revisions extension in revset #5871, I noticed "jj
abandon" attempted to re-abandon hidden revisions. This could be worked around
by repo.transform_descendants(), but I'm not sure whether the repo API should
ignore hidden revisions which are explicitly specified.
In any case, I don't think "jj abandon" should say hidden revisions get
abandoned.
The output looks better if the graph had long parallel history. "--limit=N" is
applied after sorting for consistency with "jj log". The doc also mentions that.
Since TopoGroupedGraphIterator emits predecessors in reverse order at squash
point, we no longer need to tweak the visiting order by walk_predecessors().
There's no technical reason to restrict the starting revisions to a single
commit, and it will be nice that we can see evolution history of duplicated,
split, or divergent commits.
We use a query `heads | (domain & ::heads & files(path))` in annotation process,
and it was silly that the whole expression was filtered within `all()`. We
should instead evaluate `heads | filter_within(domain & ::heads, files(path))`.
Fixes#6713
Since divergence doesn't mean the commit has been squashed from / split into
multiple commits, it doesn't make much sense to show divergent commits as a
single entry. So this patch turns "changes" into a map indexed by CommitId in
order to track divergent commits individually. The ModifiedChange type is also
reorganized accordingly.
If old commits had divergence, we can't reliably associate new commit with the
old one. In the original implementation, we worked around the problem by not
displaying diffs for such changes. In this patch, the latest "old" commit is
arbitrarily chosen. I think this is better than disabling diffs, and will help
integrating predecessors information. Change-id based deduction won't be used
if new commits exist in the predecessors map.
This basically means that the graph is sorted by "new" commits, then abandoned
commits follow. I'm thinking of integrating predecessors information into "op
diff", and it will make sense to identify changes by commit ids instead of
change ids there. Divergent commits will be displayed individually, and squashed
commits will have all predecessor commits including ones having different change
ids.
This should also fix "graph has cycle" issue. In the original implementation, we
mixed parent change ids of both new and old views, which could result in cycle.
Unfortunately, we can't reproduce a merge in bit-exact manner. The shape of the
commits graphs should be identical, but commit/change ids differ. I don't think
we would want to see the list of "identical" changes, so this patch disables
show_op_diff() for merge operations. "op diff" is unchanged because it doesn't
fail, and the diff functionality might be useful for debugging problems.
Alternatively, we could show diff from the auto-merge state without rebasing
descendants, but I don't think that would be useful either. The state before
rebase_descendants() isn't visible to users, so it shouldn't be the stuff the
user would care about.
Fixes#4465
This patch adds a `TreeValue::File::copy_id` field. The copy ids are
always empty for now. I preserved the copy id where it was easy to do
so, plus in a few non-trivial cases. In other places, however, I made
the code use a new copy id. I added a `CopyId::placeholder()`
function for creating a new copy id where we need one. We should
eventually fix all callers to either preserve an existing copy or to
generate a new one.
While the existing test checks that the schema defaults are consistent
with the output of `jj config get` (with default config), it would not
find type errors like the ones fixed in e9da94e.
This add another test case which validates the synthetic TOML containing
the default values according to the schema against the schema itself.
Because the datatests don't use the default libtest harness, datatests
and normal tests cannot be mixed in the same module or even binary.
`test_config_schema` is renamed, both to reflect that it is unlike the
other `test_*` modules, but also to make the name available for "normal"
tests related to the config schema.
Extracts the `"default"` values from the schema and creates a synthetic
TOML file holding all the defaults according to the schema. This is done
through some `jq` magic and is not perfect but rather a best effort.
If `jq` is not available, the test is skipped; in CI `jq` is required.
The test then run `jj config get` in the test env for each key in that
defaults file and compares the resulting value with the schema default.
For a few keys, there are actually no defaults known to `jj config get`,
because they are hard-coded or dynamic. These exceptions are intercepted
and explained in the test.
I had a report from a user at Google who was confused about a config
deprecation message because they had forgotten that they set a
repo-level config. This patch includes the source level in the warning
message. Hopefully that's sufficient. We could of course print the
path too, but that would make the message much longer so we would have
to split it up on two lines and I'm not sure it's worth it.
