ilyagr.bsky.social
commits
When called with `--tool :builtin-web`, `jj` will start a local web server and
open a web browser with a GUI to edit the diff. See
https://github.com/ilyagr/diffedit3 for more details (or to run it as a
standalone executable). This is the diff editor previously advertised in
https://github.com/martinvonz/jj/discussions/3094, based on CodeMirror5, with
some improvements since.
I would like to bundle it with `jj` so that everybody has access to a GUI diff
editor that can be run locally or over SSH (with port forwarding). It is
intended for situations where it is a fuss (or impossible) for a user to install
Meld and use the `meld-3` configuration.
Some TODOs and thoughts:
- This diff editor is somewhat restricted; it will ignore symlinks and currently
has no support for executable bits for example. There are some known bugs, see
e.g. the end of [the `diffedit3
README](https://github.com/ilyagr/diffedit3/?tab=readme-ov-file#shorter-term-todos-and-known-bugs).
I'm hoping it's already usable.
- Bundling the diff editor seems to add ~1.5MB to the `jj` binary. This is more
than I expected. Unless there's a way to optimize this, I'm thinking of making
the diff editor an optional feature, but I'd like it enabled by default, at
least in release binaries. Or we could not worry about it.
- I'm considering folding the `diffedit3` repo (or the majority of it) into the
jj source repo, so that it benefits from Dependabot, established code review
procedures, and the reviewers we have for `jj`. The downside is that `jj` will
then contain some Typescript code. However, there will be no need to install
`node` or `npm` *unless* you are specifically working on the webapp; the
"compiled" webapp is included in the repo.
- Currently, `:builtin-web` works just like an external diff editor, creating a
temporary directory on disk and then modifying it. At some point, we might want
to switch to keeping the tree in-memory.
For example,
```
<<<<<<< Conflict 1 of 3
+++++++ Contents of side #1
left 3.1
left 3.2
left 3.3
%%%%%%% Changes from base to side #2
-line 3
+right 3.1
>>>>>>>
```
or
```
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
-line 3
+right 3.1
+++++++ Contents of side #2
left 3.1
left 3.2
left 3.3
>>>>>>>
```
Currently, there is no way to disable these, this is TODO for a future
PR. Other TODOs for future PRs: make these labels configurable. After
that, we could support a `diff3/git`-like conflict format as well, in
principle.
Counting conflicts helps with knowing whether you fixed all the
conflicts while you are in the editor.
While labeling "side #1", etc, does not tell you the commit id or
description as requested in #1176, I still think it's an improvement.
Most importantly, I hope this will make `jj`'s conflict format less
scary-looking for new users.
I've used this for a bit, and I like it. Without the labels, I would see
that the two conflicts have a different order of conflict markers, but I
wouldn't be able to remember what that means. For longer diffs, it can
be tricky for me to quickly tell that it's a diff as opposed to one of
the sides. This also creates some hope of being able to navigate a
conflict with more than 2 sides.
Another not-so-secret goal for this is explained in
https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The
idea is a little weird, but I *think* it could be helpful, and I'd like
to experiment with it.
The format is 7 characters of the separator followed by a space and arbitrary
text, followed by a newline. Separator followed by a newline is also allowed.
E.g.:
<<<<<<< Random text
%%%%%%% Random text
line 2
-line 3
+left
line 4
+++++++ Random text
right
%%%%%%% Random text
line 2
+forward
line 3
line 4
>>>>>>> Random text
This commit only allows reading such conflicts.
I considered allowing longer separators (`<<<<<<<<<<<<<< Random text`), but we
wouldn't currently write them, so let's be strict for now.
7 characters if they are followed by a space and arbitrary text
I've heard of one instance of a person being confused by the error.
Previously, the error was:
```
Error: Failed to load tool configuration
Caused by: To use `diffedit3` as a merge tool, the config `merge-tools.diffedit3.merge-args` must be defined (see docs for details)
```
Now, it is:
```
Error: The tool `diffedit3` cannot be used as a merge tool with `jj resolve`.
Hint: To use `diffedit3` as a merge tool, the config `merge-tools.diffedit3.merge-args` must be defined (see docs for details)
```
TODO for future PR: allow setting `merge-tools.TOOL.edit-args = false` so that
attempting to use TOOL as a diff editor fails. This would be helpful, for
example, for the `vscode` tool.
Follows up on #3599. I also moved the discussion of other diff editors to a
footnote, as it didn't seem to fit well into the flow of the text.
We replaced it by `revsets.log` in 0.8.0, which is long enough that
users should have been able to switch.
I wanted to have a reference point for the built-in revsets,
but `jj config get revsets.log` doesn't turn anything up since
it has special handling for the legacy config key
`ui.default-revset`. So I had to dig into the source code of jj
to get it.
I think it might help others to be able to reason about revsets
to have the log default shown in the settings documentation.
Note that find_source_parse_error_hint() has recursion, but it should terminate
because err.source() shouldn't have a cycle.
This is basically a template version of print_branch_target().
I considered adding RefTarget template type, but some of the methods naturally
fit to RefName. For example, a conflicted branch name is decorated as "??", so
it makes sense to add branch.conflict() instead of branch.target().conflict().
I'm not pretty sure how many RefName methods we'll need to add to port the
current branch listing, but there will be .tracked(), .tracking_local_present(),
.ahead_by(), and .behind_by().
"working_copy tag" wouldn't be needed, but is added for consistency.
I'm going to add more detailed output there. This is a step towards "branch
list" template. "tag list -T" wouldn't be that useful, but it shares primitives
with "branch list -T".
I'll update the test to include conflicted tag, which can't be easily set up
by fetching from remote.
It will be called from cmd_tag_list().
I'm going to add ref_name.target*() template methods so the commit templater
can be reused for branches/tags templates. RefTarget could be looked up by
(name, kind) pair, but it's simpler to store it in RefName.
Bumps the cargo-dependencies group with 1 update: [serde](https://github.com/serde-rs/serde).
Updates `serde` from 1.0.199 to 1.0.200
- [Release notes](https://github.com/serde-rs/serde/releases)
- [Commits](https://github.com/serde-rs/serde/compare/v1.0.199...v1.0.200)
---
updated-dependencies:
- dependency-name: serde
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
Thanks to everyone who's contributed!
Unlike previous releases, I went through the changelog entries and
reorganized them a bit.
We didn't have anything under "Deprecations" this time, but I moved
the heading after "Breaking changes" for next release. I think
breaking changes are more important because deprecations are just
about giving a heads up before it actually breaks.
Bumps the cargo-dependencies group with 2 updates: [pest](https://github.com/pest-parser/pest) and [pest_derive](https://github.com/pest-parser/pest).
Updates `pest` from 2.7.9 to 2.7.10
- [Release notes](https://github.com/pest-parser/pest/releases)
- [Commits](https://github.com/pest-parser/pest/compare/v2.7.9...v2.7.10)
Updates `pest_derive` from 2.7.9 to 2.7.10
- [Release notes](https://github.com/pest-parser/pest/releases)
- [Commits](https://github.com/pest-parser/pest/compare/v2.7.9...v2.7.10)
---
updated-dependencies:
- dependency-name: pest
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: pest_derive
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
We shouldn't panic if we fail to read a tree from the backend.
This is just a little refactoring to prepare for using
`transform_descendants()`.
Before this patch, we would abandon the source commit if it became
empty after applying the reverse diff. This changes that condition to
the equivalent condition of the selected tree being the source
commit's original tree. This will help us rewrite the code to use
`transform_descendants()`.
We already have two uses for this function and I think we're soon
going to have more.
The function record the old commit as abandoned with the new parents,
which is typically what you want. We could record it as abandoned with
the old parents instead but then we'd have to do an extra iteration to
find the parents when rebasing any children. It would also be
confusing if
`rewriter.set_parents(new_parents).record_abandoned_commit()` didn't
respect the new parents.
We didn't have any tests with `jj squash` with multiple source commits
and no matching paths.
Bumps the cargo-dependencies group with 1 update: [libc](https://github.com/rust-lang/libc).
Updates `libc` from 0.2.153 to 0.2.154
- [Release notes](https://github.com/rust-lang/libc/releases)
- [Commits](https://github.com/rust-lang/libc/compare/0.2.153...0.2.154)
---
updated-dependencies:
- dependency-name: libc
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
docs: Add information about configuring delta pager
docs: only mention pager, not diff
Bumps the cargo-dependencies group with 2 updates: [serde](https://github.com/serde-rs/serde) and [unicode-width](https://github.com/unicode-rs/unicode-width).
Updates `serde` from 1.0.198 to 1.0.199
- [Release notes](https://github.com/serde-rs/serde/releases)
- [Commits](https://github.com/serde-rs/serde/compare/v1.0.198...v1.0.199)
Updates `unicode-width` from 0.1.11 to 0.1.12
- [Commits](https://github.com/unicode-rs/unicode-width/compare/v0.1.11...v0.1.12)
---
updated-dependencies:
- dependency-name: serde
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: unicode-width
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
The `move_commits` function accepts a set of target commits to shift to
a new location given by `new_parents` and `new_children`. The roots of
the target set will be reparented onto `new_parents`. `new_children`
will then be reparented onto the heads of the target set.
The commits will be rebased in reverse topological order based on the
new set of parents of each commit, which avoids the need for multiple
sets of rebase operations.
Spotted while experimenting with "jj tag list -T". The description_placeholder
alias could be changed to function taking a Commit object, but I feel it's odd.
Conceptually, the placeholder could also be used in "op log" templates.
If "branch"/"tag list" are migrate to templates, the added alias function
will be called from these templates.
This helps extract commit_summary template as an alias function.
Suppose we add binary comparison operators, we'll probably need an easy way to
get (lhs, rhs) property types to produce a meaningful error message.
When called with `--tool :builtin-web`, `jj` will start a local web server and
open a web browser with a GUI to edit the diff. See
https://github.com/ilyagr/diffedit3 for more details (or to run it as a
standalone executable). This is the diff editor previously advertised in
https://github.com/martinvonz/jj/discussions/3094, based on CodeMirror5, with
some improvements since.
I would like to bundle it with `jj` so that everybody has access to a GUI diff
editor that can be run locally or over SSH (with port forwarding). It is
intended for situations where it is a fuss (or impossible) for a user to install
Meld and use the `meld-3` configuration.
Some TODOs and thoughts:
- This diff editor is somewhat restricted; it will ignore symlinks and currently
has no support for executable bits for example. There are some known bugs, see
e.g. the end of [the `diffedit3
README](https://github.com/ilyagr/diffedit3/?tab=readme-ov-file#shorter-term-todos-and-known-bugs).
I'm hoping it's already usable.
- Bundling the diff editor seems to add ~1.5MB to the `jj` binary. This is more
than I expected. Unless there's a way to optimize this, I'm thinking of making
the diff editor an optional feature, but I'd like it enabled by default, at
least in release binaries. Or we could not worry about it.
- I'm considering folding the `diffedit3` repo (or the majority of it) into the
jj source repo, so that it benefits from Dependabot, established code review
procedures, and the reviewers we have for `jj`. The downside is that `jj` will
then contain some Typescript code. However, there will be no need to install
`node` or `npm` *unless* you are specifically working on the webapp; the
"compiled" webapp is included in the repo.
- Currently, `:builtin-web` works just like an external diff editor, creating a
temporary directory on disk and then modifying it. At some point, we might want
to switch to keeping the tree in-memory.
For example,
```
<<<<<<< Conflict 1 of 3
+++++++ Contents of side #1
left 3.1
left 3.2
left 3.3
%%%%%%% Changes from base to side #2
-line 3
+right 3.1
>>>>>>>
```
or
```
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
-line 3
+right 3.1
+++++++ Contents of side #2
left 3.1
left 3.2
left 3.3
>>>>>>>
```
Currently, there is no way to disable these, this is TODO for a future
PR. Other TODOs for future PRs: make these labels configurable. After
that, we could support a `diff3/git`-like conflict format as well, in
principle.
Counting conflicts helps with knowing whether you fixed all the
conflicts while you are in the editor.
While labeling "side #1", etc, does not tell you the commit id or
description as requested in #1176, I still think it's an improvement.
Most importantly, I hope this will make `jj`'s conflict format less
scary-looking for new users.
I've used this for a bit, and I like it. Without the labels, I would see
that the two conflicts have a different order of conflict markers, but I
wouldn't be able to remember what that means. For longer diffs, it can
be tricky for me to quickly tell that it's a diff as opposed to one of
the sides. This also creates some hope of being able to navigate a
conflict with more than 2 sides.
Another not-so-secret goal for this is explained in
https://github.com/martinvonz/jj/pull/3109#issuecomment-2014140627. The
idea is a little weird, but I *think* it could be helpful, and I'd like
to experiment with it.
The format is 7 characters of the separator followed by a space and arbitrary
text, followed by a newline. Separator followed by a newline is also allowed.
E.g.:
<<<<<<< Random text
%%%%%%% Random text
line 2
-line 3
+left
line 4
+++++++ Random text
right
%%%%%%% Random text
line 2
+forward
line 3
line 4
>>>>>>> Random text
This commit only allows reading such conflicts.
I considered allowing longer separators (`<<<<<<<<<<<<<< Random text`), but we
wouldn't currently write them, so let's be strict for now.
7 characters if they are followed by a space and arbitrary text
I've heard of one instance of a person being confused by the error.
Previously, the error was:
```
Error: Failed to load tool configuration
Caused by: To use `diffedit3` as a merge tool, the config `merge-tools.diffedit3.merge-args` must be defined (see docs for details)
```
Now, it is:
```
Error: The tool `diffedit3` cannot be used as a merge tool with `jj resolve`.
Hint: To use `diffedit3` as a merge tool, the config `merge-tools.diffedit3.merge-args` must be defined (see docs for details)
```
TODO for future PR: allow setting `merge-tools.TOOL.edit-args = false` so that
attempting to use TOOL as a diff editor fails. This would be helpful, for
example, for the `vscode` tool.
I wanted to have a reference point for the built-in revsets,
but `jj config get revsets.log` doesn't turn anything up since
it has special handling for the legacy config key
`ui.default-revset`. So I had to dig into the source code of jj
to get it.
I think it might help others to be able to reason about revsets
to have the log default shown in the settings documentation.
I considered adding RefTarget template type, but some of the methods naturally
fit to RefName. For example, a conflicted branch name is decorated as "??", so
it makes sense to add branch.conflict() instead of branch.target().conflict().
I'm not pretty sure how many RefName methods we'll need to add to port the
current branch listing, but there will be .tracked(), .tracking_local_present(),
.ahead_by(), and .behind_by().
Bumps the cargo-dependencies group with 1 update: [serde](https://github.com/serde-rs/serde).
Updates `serde` from 1.0.199 to 1.0.200
- [Release notes](https://github.com/serde-rs/serde/releases)
- [Commits](https://github.com/serde-rs/serde/compare/v1.0.199...v1.0.200)
---
updated-dependencies:
- dependency-name: serde
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
Thanks to everyone who's contributed!
Unlike previous releases, I went through the changelog entries and
reorganized them a bit.
We didn't have anything under "Deprecations" this time, but I moved
the heading after "Breaking changes" for next release. I think
breaking changes are more important because deprecations are just
about giving a heads up before it actually breaks.
Bumps the cargo-dependencies group with 2 updates: [pest](https://github.com/pest-parser/pest) and [pest_derive](https://github.com/pest-parser/pest).
Updates `pest` from 2.7.9 to 2.7.10
- [Release notes](https://github.com/pest-parser/pest/releases)
- [Commits](https://github.com/pest-parser/pest/compare/v2.7.9...v2.7.10)
Updates `pest_derive` from 2.7.9 to 2.7.10
- [Release notes](https://github.com/pest-parser/pest/releases)
- [Commits](https://github.com/pest-parser/pest/compare/v2.7.9...v2.7.10)
---
updated-dependencies:
- dependency-name: pest
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: pest_derive
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
We already have two uses for this function and I think we're soon
going to have more.
The function record the old commit as abandoned with the new parents,
which is typically what you want. We could record it as abandoned with
the old parents instead but then we'd have to do an extra iteration to
find the parents when rebasing any children. It would also be
confusing if
`rewriter.set_parents(new_parents).record_abandoned_commit()` didn't
respect the new parents.
Bumps the cargo-dependencies group with 1 update: [libc](https://github.com/rust-lang/libc).
Updates `libc` from 0.2.153 to 0.2.154
- [Release notes](https://github.com/rust-lang/libc/releases)
- [Commits](https://github.com/rust-lang/libc/compare/0.2.153...0.2.154)
---
updated-dependencies:
- dependency-name: libc
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
Bumps the cargo-dependencies group with 2 updates: [serde](https://github.com/serde-rs/serde) and [unicode-width](https://github.com/unicode-rs/unicode-width).
Updates `serde` from 1.0.198 to 1.0.199
- [Release notes](https://github.com/serde-rs/serde/releases)
- [Commits](https://github.com/serde-rs/serde/compare/v1.0.198...v1.0.199)
Updates `unicode-width` from 0.1.11 to 0.1.12
- [Commits](https://github.com/unicode-rs/unicode-width/compare/v0.1.11...v0.1.12)
---
updated-dependencies:
- dependency-name: serde
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
- dependency-name: unicode-width
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
The `move_commits` function accepts a set of target commits to shift to
a new location given by `new_parents` and `new_children`. The roots of
the target set will be reparented onto `new_parents`. `new_children`
will then be reparented onto the heads of the target set.
The commits will be rebased in reverse topological order based on the
new set of parents of each commit, which avoids the need for multiple
sets of rebase operations.