This is more visible than a comment. Once this is supported, I'm
considering removing this entirely. I doubt many people intentionally
use it, but if so, they can easily remove this warning in their config.
Another option would be to set up a file-by-file diff editing mode,
for which vimdiff would be fine.
Since 7618b52b "cli: consider 'JJ:' lines as comments also when not followed by
space", lines starting with "JJ:" (without space) are also ignored. We can
simply add "JJ:" prefix to empty intro/instruction lines.
Closes#5484
This helps detect whether the last line is "JJ:" instruction or not. It seems
also nice that I don't have to insert newline to reflow the edited paragraph.
This reverts commit b8ca9ae and adds a comment.
In commit 4d42604 (a year ago), we started writing the trees involved in
conflicted commits to the Git commit object in addition to the proto
storage. We validated that the two record matched when reading commits
until as recently as f7b14be (about a week ago). Just after that, in
commit b8ca9ae, we stopped writing the tree ids to the proto storage.
That means that any version of jj between 4d42604 and f7b14be would
error fail when reading a conflicted commit created by new versions.
While we don't guarantee forward compatibility, it's easy to do so here,
so let's be friendly to older versions by rolling back b8ca9ae so we
continue to write the conflicted tree ids to both places for a while
more.
(Thanks to Martin for the detailed explanation!)
Fixes https://github.com/jj-vcs/jj/issues/6185
A subset of cli tests could fail if the system /etc/gitconfig had
configuration interfering with the tests. The cause seems to be running
of `jj` commands that would in turn use a `git` subprocess.
Fix this by setting `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL`, like
in `hermetic_git`.
Fixes#6159
When rendering diff of conflicts, it might make sense to show diff of negative
(or base) terms with "removed"/"added" labels swapped. For example, diffs
between A and B-C+D can be rendered as
{left, right} = {A (-), B (+)}, {A (+), C (-)}, {A (-), D (+)}
by padding -A+A to the left side. To achieve that, I'm thinking of adding
labels: [&str; 2] parameter. This patch will help keep function arguments more
consistent there.
FWIW, I also tried rendering in {A (-), B (+)}, {C (-), D (+)} forms. This
seemed not intuitive because, when diffing, we compare two distinct states. In
the example above, the diff {C, D} should be considered an internal state at the
right side, not the states pair to be diffed.
I think this makes more sense because WorkspaceId is currently a human-readable
name. In error/status messages, workspace names are now printed in revset
syntax.
New WorkspaceId types do not implement Default. It would be weird if string-like
type had non-empty Default::default(). The DEFAULT constant is provided instead.
It seemed inconsistent that only GitExportError was translated to an internal
error. There are various reasons that triggers git::export_refs()/reset_head()
failure, and some of them are environmental error.
Wrapped errors are usually displayed after "Failed to import refs ...", etc., so
the context is obvious. I also removed "Internal"/"Error" for consistency.
The option will be used to prioritize branches of the `jj log` graph to
be displayed on the left.
This can make them more readable in some situations.
An example would be
```
[revsets]
log-graph-prioritize = "coalesce(description("megamerge\n"), trunk())"
```
In the diagram, E has parent B, and D has parents B and C, so the fork point of E and D
(the most downstream common ancestor of these commits) should be B rather than A.
This avoids having to escape double and single quotes used within page names. One page has double quotes in its name in the current state, and another will have a single quote in its name in the next commit.
As discussed several times before, we want to restrict permission to
approve PRs to the maintainers only. This patch adds a GitHub
CODEOWNERS file for that purpose. Once this has been merged, I'm going
to update the rulesets to make PRs requires approval from a
maintainer.
