ilyagr.bsky.social
commits
Bumps the github-dependencies group with 1 update: [taiki-e/install-action](https://github.com/taiki-e/install-action).
Updates `taiki-e/install-action` from 2.48.11 to 2.48.13
- [Release notes](https://github.com/taiki-e/install-action/releases)
- [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/taiki-e/install-action/compare/297054b27414ad8086f67963ce1033c02fe309c3...ad0904967b4c8e3005f6ed2efa1fa74dd9a05f32)
---
updated-dependencies:
- dependency-name: taiki-e/install-action
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: github-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
In the case where the user has set `snapshot.auto-track` to something
other than `all()`, running `jj st` with a higher file size set just for
that command will not actually fix the user's problem, `jj file track`
needs to be called instead.
Some working-copy implementations, like the Google CitC one, may want
to update the VFS's state even if the tree didn't change. In
particular, when updating between two commits with the same tree but
different mainline base, we want to update the base commit. Otherwise
a future snapshot, which we do relative to the mainline commit, may
notice an incorrect set of changed file.
When updating to the same tree, we can skip the actual update and skip
writing the tree-state file.
When updating the working copy results in no changes, we currently
return `None` from `cli_util::update_working_copy()`. However, a no-op
update is still an update, so I think it makes more sense to always
return a `CheckoutStats`. We already skip printing stats if they're
zero.
Forgetting remote bookmarks can lead to surprising behavior since it
causes the repo state to become out-of-sync with the remote until the
next `jj git fetch`. Untracking the bookmarks should be a simpler and
more intuitive default behavior. The old behavior is still available
with the `--include-remotes` flag.
I also changed the displayed number of forgotten branches. Previously
when forgetting "bookmark", "bookmark@remote", and "bookmark@git" it
would display `Forgot 1 bookmarks`, but I think this would be confusing
with the new flag since the user might think that `--include-remotes`
didn't work. Now it shows separate `Forgot N local bookmarks` and
`Forgot M remote bookmarks` messages when applicable.
It was added at 3c80e3453db6 "cli: branch: make "set" do upsert as before" in
order to remind behavior change.
Same as `format_short_change_id`.
We can't use `format_short_id` because `operation.id()` does not have `shortest()` method.
The condition we were checking (which I suggested during review) is
very broken. It checks if the new view is equal to view before the
current operation, but that's supposed to always be true (except for
operation that update remote bookmarks). The reason the warning didn't
trigger all the time was that we did the comparison after calling
`merge_view()` but before calling `rebase_descendants()` (via
`tx.finish()`). The former only records commits as abandoned without
actually hiding them. However, because of [the hack][hack] in
`merge_view()` to make it work reasonably well in huge repos, every
undo operation at Google would print the warning.
This patch fixes the bug by checking if the to-be-undone operation is
an undo by comparing its view to its grandparent's view.
[hack]: https://github.com/jj-vcs/jj/blob/ec6f8278fd87d6276d457a5e55dd1778b3a4aa00/lib/src/repo.rs#L1693-L1708
Will be fixed in the next patch.
After even more discussion on Discord, we decided to use the new bookmark
behavior immediately and only print a warning during `jj split` if the user has
opted out of the new behavior using the `split.legacy-bookmark-behavior` config
setting.
The reasoning is that if the behavior change breaks someone's workflow or is
very disruptive, they are likely to check the changelog and learn about the
config option. For users that are not adversely impacted, printing a warning
that can only be silenced by changing their config is also disruptive.
#3419
This should be safer, and should be okay since we ignore invalid file names when
scanning the store directories.
Fixes #5712
I'm going to add helper functions that return these directory paths.
I originally thought we would have to add BString template type first, but we
can use opaque Template type instead.
Also renamed data to line as the type name was changed to AnnotationLine.
Bumps the github-dependencies group with 2 updates: [taiki-e/install-action](https://github.com/taiki-e/install-action) and [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv).
Updates `taiki-e/install-action` from 2.48.10 to 2.48.11
- [Release notes](https://github.com/taiki-e/install-action/releases)
- [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/taiki-e/install-action/compare/ae9d9ea210235f03e365c28f43504df735a511be...297054b27414ad8086f67963ce1033c02fe309c3)
Updates `astral-sh/setup-uv` from 4.2.0 to 5.2.2
- [Release notes](https://github.com/astral-sh/setup-uv/releases)
- [Commits](https://github.com/astral-sh/setup-uv/compare/v4.2...4db96194c378173c656ce18a155ffc14a9fc4355)
---
updated-dependencies:
- dependency-name: taiki-e/install-action
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: github-dependencies
- dependency-name: astral-sh/setup-uv
dependency-type: direct:production
update-type: version-update:semver-major
dependency-group: github-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
Allows:
* self.commit()
* self.line_number()
* self.first_line_in_hunk()
Certain pagers (like `delta`), when used for `git blame`, only show the
commit information for the first line in a hunk. This would be a nice
addition to `jj file annotate`.
`jj file annotate` already uses a template to control the rendering of
commit information --- `templates.annotate_commit_summary`. Instead of
a custom CLI flag, the tools necessary to do this should be available in
the template language.
If `1 % 2` or `1.is_even()` was available in the template language, this
would also allow alternating colors (using `raw_escape_sequence`).
Example:
```toml
[templates]
# only show commit info for the first line of each hunk
annotate_commit_summary = '''
if(first_line_in_hunk,
show_commit_info(commit),
pad_end(20, " "),
)
'''
```
This removes some dependencies on very old versions of the `dirs`
crate and a few others. Thanks to @quark-zju for getting a new
`sapling-streampager` released.
There's currently no way to tell what `jj fix` is doing. This adds some
traces such that `jj fix --debug` will at least tell you what's being
run and what it's exit code is, similar to other subprocessing code.
Also simplify the `hidden()` revset with it.
This was discussed in the Discord a while ago, and this is the logical and consistent
conclusion. Implementing it as such makes it consistent with both `jj edit` and `jj new`
which make hidden commits such as predecessors visible.
This actually was Martins work, I just added the tests.
Co-Authored-by: martinvonz <martinvonz@google.com>
This should help us catch GHA security issues earlier.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
In theory this could be exploited by a contributor who pushes a tag with a
specifically crafted name in order to exfiltrate a `GITHUB_TOKEN` that has
permissions on the jj repository. This token would be scoped narrowly ideally,
but...
Today, Martin does releases manually, so this workflow currently does not e.g.
have the ability to upload a compromised package to crates.io. However in the
future we'd like to have the release done automatically via workflow as well,
which would make this potential injection vector catastrophic if the injection
was possible in a step with a crates.io API token available.
Found by `zizmor`.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Found by `zizmor`.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Found by `zizmor`.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Found by `zizmor`.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The dependabot workflow already specifies the exact permissions it needs within
the workflow steps, so there's no need to enable any default permissions.
Found by `zizmor`.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This stops issuing overly broad permissions to the entire workflow and instead
scopes them to the necessary steps in the job.
Found by `zizmor`.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Set up tests using `taplo check --schema` to validate the default configs.
Install taplo in GitHub CI and in the Nix flake.
Fixes #5670.
It only occurred to me after I rebuilt jj and actually had to run the command
that we should probably recommend a change to the user config instead of the
repo config.
#3419
It seems a bit safer to set up the working directory by caller who knows the
test environment directory exists.
Since we don't set up Git worktree properly, it's odd that init_git_repo() has
a option to create a workspace at the specified path.
It's also useful to remove color labels from the inner template.
It's easier to parse than \".
This adds a record of all contributing employees of companies who pay
for contributions. The purpose is to help make possible conflicts of
interest easier to spot. As far as we know, only Google currently pays
right now.
Currently, `jj split` moves bookmarks from the target revision to the second
revision created by the split. Since the first revision inherits the change id
of the target revision, moving the bookmarks to the first revision is less
surprising (i.e. the bookmarks stay with the change id). This no-implicit-move
behavior also aligns with how `jj abandon` drops bookmarks instead of moving
them to the parent revision.
Two releases from now, `jj split` will no longer move bookmarks to the second
revision created by the split. Instead, local bookmarks associated with the
target revision will move to the first revision created by the split (which
inherits the target revision's change id). You can opt out of this change by
setting `split.legacy-bookmark-behavior = true`, but this will likely be
removed in a future release. You can also try the new behavior now by setting
`split.legacy-bookmark-behavior = false`.
Users who have not opted into the new behavior via the config setting will see
a warning when they run `jj split` informing them about the change. The default
behavior be changed in the future.
The `jj split` tests for bookmarks are updated to run in all three configurations:
- Config setting enabled
- Config setting disabled
- Config setting unset
#3419
Bumps the github-dependencies group with 1 update: [taiki-e/install-action](https://github.com/taiki-e/install-action).
Updates `taiki-e/install-action` from 2.48.9 to 2.48.10
- [Release notes](https://github.com/taiki-e/install-action/releases)
- [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/taiki-e/install-action/compare/995f97569c4a8ae84dcd7e1a0107f65ca6ebf139...ae9d9ea210235f03e365c28f43504df735a511be)
---
updated-dependencies:
- dependency-name: taiki-e/install-action
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: github-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
It's been about five months, and it seems best to occasionally try
updating. Let's see if this causes any problems.
There was also a minor breaking change to
`mkdocs-include-markdown-plugin`, I added an option to keep
the old behavior (which seems nice in this case).
To do these kinds of updates, `uv tree --outdated` is useful.
`gix::Repository` instances are larger than 1KB on 64-bit machines. This
makes Clippy warn about an unbalance between variants of `GitFetchImpl`:
the `Git2` variant requires 8 bytes, while the `Subprocess` variant
requires 1128 bytes.
Boxing the `gix::Repository` makes `GitFetchImpl` instances smaller, as
well as the other structs embedding them such as `GitFetch`.
Removes nonexistent Sublime TOML LSP server link. Since I wasn't able to find an alternative, I removed the Sublime bit entirely.
The fix settings weren't indented consistent with the rest of the settings,
causing them to appear in the redacted snapshot in the test_util_config_schema
test.
Bumps the cargo-dependencies group with 1 update: [clap](https://github.com/clap-rs/clap).
Updates `clap` from 4.5.28 to 4.5.29
- [Release notes](https://github.com/clap-rs/clap/releases)
- [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md)
- [Commits](https://github.com/clap-rs/clap/compare/clap_complete-v4.5.28...clap_complete-v4.5.29)
---
updated-dependencies:
- dependency-name: clap
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
In addition to a single string, the `ui.editor` and `ui.diff.tool` options also
allow arrays of strings. `ui.pager` allows arrays of strings as well as a nested
table describing both the command and the environment.
Update config-schema.json to allow all of these types of values.
Fixes #5617
We are planning to add a config option that controls how bookmarks and change
ids move during `jj split` based on feedback in https://github.com/jj-vcs/jj/pull/5618.
I think the tests will be more readable after the config option is added if we
move the bookmark testing to its own test.
#3419
cargo-insta was re-run.
This is due to centralizing git interaction code to use a particular
different signature, which changes the commit hashes
These are helpers for:
- gitlinks
- removing config values
- symbolic references
- status
- index management
Since git CLI appends " " to sideband messages to overwrite the previous
line, we need to undo that. Our GitSidebandProgressMessageWriter expects
original sideband messages.
Bumps the github-dependencies group with 1 update: [taiki-e/install-action](https://github.com/taiki-e/install-action).
Updates `taiki-e/install-action` from 2.48.11 to 2.48.13
- [Release notes](https://github.com/taiki-e/install-action/releases)
- [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/taiki-e/install-action/compare/297054b27414ad8086f67963ce1033c02fe309c3...ad0904967b4c8e3005f6ed2efa1fa74dd9a05f32)
---
updated-dependencies:
- dependency-name: taiki-e/install-action
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: github-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
Some working-copy implementations, like the Google CitC one, may want
to update the VFS's state even if the tree didn't change. In
particular, when updating between two commits with the same tree but
different mainline base, we want to update the base commit. Otherwise
a future snapshot, which we do relative to the mainline commit, may
notice an incorrect set of changed file.
Forgetting remote bookmarks can lead to surprising behavior since it
causes the repo state to become out-of-sync with the remote until the
next `jj git fetch`. Untracking the bookmarks should be a simpler and
more intuitive default behavior. The old behavior is still available
with the `--include-remotes` flag.
I also changed the displayed number of forgotten branches. Previously
when forgetting "bookmark", "bookmark@remote", and "bookmark@git" it
would display `Forgot 1 bookmarks`, but I think this would be confusing
with the new flag since the user might think that `--include-remotes`
didn't work. Now it shows separate `Forgot N local bookmarks` and
`Forgot M remote bookmarks` messages when applicable.
The condition we were checking (which I suggested during review) is
very broken. It checks if the new view is equal to view before the
current operation, but that's supposed to always be true (except for
operation that update remote bookmarks). The reason the warning didn't
trigger all the time was that we did the comparison after calling
`merge_view()` but before calling `rebase_descendants()` (via
`tx.finish()`). The former only records commits as abandoned without
actually hiding them. However, because of [the hack][hack] in
`merge_view()` to make it work reasonably well in huge repos, every
undo operation at Google would print the warning.
This patch fixes the bug by checking if the to-be-undone operation is
an undo by comparing its view to its grandparent's view.
[hack]: https://github.com/jj-vcs/jj/blob/ec6f8278fd87d6276d457a5e55dd1778b3a4aa00/lib/src/repo.rs#L1693-L1708
After even more discussion on Discord, we decided to use the new bookmark
behavior immediately and only print a warning during `jj split` if the user has
opted out of the new behavior using the `split.legacy-bookmark-behavior` config
setting.
The reasoning is that if the behavior change breaks someone's workflow or is
very disruptive, they are likely to check the changelog and learn about the
config option. For users that are not adversely impacted, printing a warning
that can only be silenced by changing their config is also disruptive.
#3419
Bumps the github-dependencies group with 2 updates: [taiki-e/install-action](https://github.com/taiki-e/install-action) and [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv).
Updates `taiki-e/install-action` from 2.48.10 to 2.48.11
- [Release notes](https://github.com/taiki-e/install-action/releases)
- [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/taiki-e/install-action/compare/ae9d9ea210235f03e365c28f43504df735a511be...297054b27414ad8086f67963ce1033c02fe309c3)
Updates `astral-sh/setup-uv` from 4.2.0 to 5.2.2
- [Release notes](https://github.com/astral-sh/setup-uv/releases)
- [Commits](https://github.com/astral-sh/setup-uv/compare/v4.2...4db96194c378173c656ce18a155ffc14a9fc4355)
---
updated-dependencies:
- dependency-name: taiki-e/install-action
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: github-dependencies
- dependency-name: astral-sh/setup-uv
dependency-type: direct:production
update-type: version-update:semver-major
dependency-group: github-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
Allows:
* self.commit()
* self.line_number()
* self.first_line_in_hunk()
Certain pagers (like `delta`), when used for `git blame`, only show the
commit information for the first line in a hunk. This would be a nice
addition to `jj file annotate`.
`jj file annotate` already uses a template to control the rendering of
commit information --- `templates.annotate_commit_summary`. Instead of
a custom CLI flag, the tools necessary to do this should be available in
the template language.
If `1 % 2` or `1.is_even()` was available in the template language, this
would also allow alternating colors (using `raw_escape_sequence`).
Example:
```toml
[templates]
# only show commit info for the first line of each hunk
annotate_commit_summary = '''
if(first_line_in_hunk,
show_commit_info(commit),
pad_end(20, " "),
)
'''
```
This was discussed in the Discord a while ago, and this is the logical and consistent
conclusion. Implementing it as such makes it consistent with both `jj edit` and `jj new`
which make hidden commits such as predecessors visible.
This actually was Martins work, I just added the tests.
Co-Authored-by: martinvonz <martinvonz@google.com>
In theory this could be exploited by a contributor who pushes a tag with a
specifically crafted name in order to exfiltrate a `GITHUB_TOKEN` that has
permissions on the jj repository. This token would be scoped narrowly ideally,
but...
Today, Martin does releases manually, so this workflow currently does not e.g.
have the ability to upload a compromised package to crates.io. However in the
future we'd like to have the release done automatically via workflow as well,
which would make this potential injection vector catastrophic if the injection
was possible in a step with a crates.io API token available.
Found by `zizmor`.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Currently, `jj split` moves bookmarks from the target revision to the second
revision created by the split. Since the first revision inherits the change id
of the target revision, moving the bookmarks to the first revision is less
surprising (i.e. the bookmarks stay with the change id). This no-implicit-move
behavior also aligns with how `jj abandon` drops bookmarks instead of moving
them to the parent revision.
Two releases from now, `jj split` will no longer move bookmarks to the second
revision created by the split. Instead, local bookmarks associated with the
target revision will move to the first revision created by the split (which
inherits the target revision's change id). You can opt out of this change by
setting `split.legacy-bookmark-behavior = true`, but this will likely be
removed in a future release. You can also try the new behavior now by setting
`split.legacy-bookmark-behavior = false`.
Users who have not opted into the new behavior via the config setting will see
a warning when they run `jj split` informing them about the change. The default
behavior be changed in the future.
The `jj split` tests for bookmarks are updated to run in all three configurations:
- Config setting enabled
- Config setting disabled
- Config setting unset
#3419
Bumps the github-dependencies group with 1 update: [taiki-e/install-action](https://github.com/taiki-e/install-action).
Updates `taiki-e/install-action` from 2.48.9 to 2.48.10
- [Release notes](https://github.com/taiki-e/install-action/releases)
- [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/taiki-e/install-action/compare/995f97569c4a8ae84dcd7e1a0107f65ca6ebf139...ae9d9ea210235f03e365c28f43504df735a511be)
---
updated-dependencies:
- dependency-name: taiki-e/install-action
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: github-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>
It's been about five months, and it seems best to occasionally try
updating. Let's see if this causes any problems.
There was also a minor breaking change to
`mkdocs-include-markdown-plugin`, I added an option to keep
the old behavior (which seems nice in this case).
To do these kinds of updates, `uv tree --outdated` is useful.
`gix::Repository` instances are larger than 1KB on 64-bit machines. This
makes Clippy warn about an unbalance between variants of `GitFetchImpl`:
the `Git2` variant requires 8 bytes, while the `Subprocess` variant
requires 1128 bytes.
Boxing the `gix::Repository` makes `GitFetchImpl` instances smaller, as
well as the other structs embedding them such as `GitFetch`.
Bumps the cargo-dependencies group with 1 update: [clap](https://github.com/clap-rs/clap).
Updates `clap` from 4.5.28 to 4.5.29
- [Release notes](https://github.com/clap-rs/clap/releases)
- [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md)
- [Commits](https://github.com/clap-rs/clap/compare/clap_complete-v4.5.28...clap_complete-v4.5.29)
---
updated-dependencies:
- dependency-name: clap
dependency-type: direct:production
update-type: version-update:semver-patch
dependency-group: cargo-dependencies
...
Signed-off-by: dependabot[bot] <support@github.com>