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
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.
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>
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>
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
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
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`.
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.
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
Since git CLI appends " " to sideband messages to overwrite the previous
line, we need to undo that. Our GitSidebandProgressMessageWriter expects
original sideband messages.
"$comment" is not officially supported by draft-4, but it is in newer
drafts, and JSON schema readers are supposed to skip fields that
are not known to them.
This makes the schema a bit less smart, but there's a good chance
`taplo` could not use "propertyNames" anyway because that comes
from a newer version of the schema than `taplo` officially supports
(see the child of this commit).
Fixes#5607
With this change a warning is shown if the user does not explicitly specify the target revision, but the behavior is unchanged (it still defaults to the working copy).
In the future the warning will be turned into an error. In other words, it will be required to specify target revision.
The bulk of the changes here are to prepare tests for the upcoming change, to make the transition easier.
For additional details please see:
* https://github.com/jj-vcs/jj/issues/5374
* https://github.com/jj-vcs/jj/discussions/5363
