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.
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.
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!
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.
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
* Added an explanation for why reverting a merge often results in an
empty commit.
* `jj revert <merge>` requires `-r`.
* Fixed backwards description of merge direction (compared to what
the graph shows).
* Minor copy editing.
This is idiosyncratic to new users coming from Git, since `jj revert <merge>` does not
usually do what users want. Maybe a followup could be adding a
warning in `jj revert`.
The explanation is from a Discord message from Austin.
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
The semantics is similar to experimental.directaccess=true in Mercurial. Hidden
revisions and their ancestors become temporarily available. This means all() is
not exactly the same as ::visible_heads(). The latter never includes hidden
revisions.
We could instead transform all() to (all() | referenced_commits). However, this
wouldn't work if expressions like ::hidden are intersected/united with filters,
all(), etc.
Fixes#5871
This was discussed in #3219 and #3262, and apparently, people don't agree
whether we should implement machine-readable formatting by using templater.
However, there are recurring requests about JSON output, and "jj api" is still
vaporware. So I think it's good to add some support for JSON output.
I'm not going to add syntax to build custom JSON object/list for now. Instead,
property types such as Commit will implement fixed serialization output. The
user might have to write ad-hoc JSON constructs to concatenate the default JSON
output and their custom JSON fields.
We'll need a documentation about which types are serializable. I think this can
be added later when more types get serialization support.
Currently, this is parsed as `x..visible_heads()`, which prevents
optimizing `x.. & ::y` to `x..y`.
An alternative would be to remove `::visible_heads()` from
intersections, similar to `all()`, but it might be better to avoid
removing `visible_heads()` if it was explictly requested by a user.
- Use `jq -s` to read the entire input (could be several arrays due to GitHub API
pagination) before running the filter just once.
- Deduplicate by `.author.login` in case a person with the same GitHub username has
commits under different names within a release.
- Use string interpolation to format each line.
This version describes a design that I think will work relatively well
for supporting copy tracing even when there are conflicts.
There are still some open questions, in particular around how to
populate the data in Git repos, and how to efficiently query the data
in very large repos like the one at Google. I think it's still clear
enough that we can start working on the implementation.
