mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2025-02-06 03:22:59 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 10
jj/cli/src/config-schema.json

360 lines
14 KiB
JSON
Raw Normal View History

Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
{
"$schema": "http://json-schema.org/draft-07/schema",
"title": "Jujutsu config",
"type": "object",
"description": "User configuration for Jujutsu VCS. See https://github.com/martinvonz/jj/blob/main/docs/config.md for details",
"properties": {
"user": {
"type": "object",
"description": "Settings about the user",
"properties": {
"name": {
"type": "string",
"description": "Full name of the user, used in commits"
},
"email": {
"type": "string",
"description": "User's email address, used in commits",
"format": "email"
}
}
},
"operation": {
"type": "object",
"description": "Metadata to be attached to jj operations (shown in jj op log)",
"properties": {
"hostname": {
"type": "string",
"format": "hostname"
},
"username": {
"type": "string"
}
}
},
"ui": {
"type": "object",
"description": "UI settings",
"properties": {
"allow-init-native": {
"type": "boolean",
"description": "Whether to allow initializing a repo with the native backend",
"default": false
},
cli: default to log when no subcommand is provided This is a convenience optimization to improve the default user experience, since `jj log` is a frequently run command. Accessing the help information explicitly still follows normal CLI conventions, and instructions are displayed appropriately if the user happens to make a mistake. Discoverability should not be adversely harmed. Note that this behavior mirrors what Sapling does [2], where `sl` will display the smartlog by default. [1] https://github.com/clap-rs/clap/issues/975 [2] https://sapling-scm.com/docs/overview/smartlog
2023-04-14 01:49:35 +00:00
"default-command": {
"type": "string",
"description": "Default command to run when no explicit command is given",
"default": "log"
},
cli: add support for setting default description That is, jj will use ui.default_description as a starting point when user is about to describe an empty change. I think it might be confusing to do this with -m / --stdin (violates WYSIWYG), so I'm only doing this when jj invokes an editor. Also, this could evolve into a proper template in the future instead of just plain text, to allow inheriting from parent change(s), for example. Partially addresses #1354.
2023-08-12 10:19:27 +00:00
"default-description": {
"type": "string",
"description": "Default description to use when describing changes with an empty description",
"default": ""
},
Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
"color": {
"description": "Whether to colorize command output",
config: add and parse `ui.log_author_format` for use in the default template Supported values are, - `none` for no author information, - `full` for both the name and email, - `name` for just the name, - `username` for username part of the email, - (default) `email` (or any other gibberish for that matter) for the full email.
2023-02-11 11:07:58 +00:00
"enum": [
"always",
"never",
"auto"
],
Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
"default": "auto"
},
configs: add the ability to disable paging via `ui.paginate`
2023-08-11 04:22:19 +00:00
"paginate": {
"type": "string",
"description": "Whether or not to use a pager",
"enum": [
"never",
"auto"
],
cli: add support for setting default description That is, jj will use ui.default_description as a starting point when user is about to describe an empty change. I think it might be confusing to do this with -m / --stdin (violates WYSIWYG), so I'm only doing this when jj invokes an editor. Also, this could evolve into a proper template in the future instead of just plain text, to allow inheriting from parent change(s), for example. Partially addresses #1354.
2023-08-12 10:19:27 +00:00
"default": "auto"
configs: add the ability to disable paging via `ui.paginate`
2023-08-11 04:22:19 +00:00
},
Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
"pager": {
"type": "string",
"description": "Pager to use for displaying command output",
"default": "less -FRX"
},
doc: include diff format in config schema
2023-02-06 06:55:15 +00:00
"diff": {
"type": "object",
"description": "Options for how diffs are displayed",
"properties": {
"format": {
"description": "The diff format to use",
config: add and parse `ui.log_author_format` for use in the default template Supported values are, - `none` for no author information, - `full` for both the name and email, - `name` for just the name, - `username` for username part of the email, - (default) `email` (or any other gibberish for that matter) for the full email.
2023-02-11 11:07:58 +00:00
"enum": [
"color-words",
"git",
"summary"
],
doc: include diff format in config schema
2023-02-06 06:55:15 +00:00
"default": "color-words"
cli: load default diff command from "ui.diff.tool" config This could be a "ui.diff.format" variant, but we would need to solve namespace problem by prefixing "tool:<name>" for example. Then, inlining command arguments would become uglier. #1886
2023-08-03 22:25:22 +00:00
},
"tool": {
"type": "string",
"description": "External tool for generating diffs"
doc: include diff format in config schema
2023-02-06 06:55:15 +00:00
}
}
},
docs: add `diff-instructions` to config schema
2023-08-11 16:51:17 +00:00
"diff-instructions": {
"type": "boolean",
"description": "Whether to generate the JJ-INSTRUCTIONS file as part of editing a diff",
"default": true
},
Add ui.graph.style into config schema
2023-01-31 06:21:49 +00:00
"graph": {
"type": "object",
"description": "Options for rendering revision graphs from jj log etc",
"properties": {
"style": {
"description": "Style of connectors/markings used to render the graph. See https://github.com/martinvonz/jj/blob/main/docs/config.md#graph-style",
config: add and parse `ui.log_author_format` for use in the default template Supported values are, - `none` for no author information, - `full` for both the name and email, - `name` for just the name, - `username` for username part of the email, - (default) `email` (or any other gibberish for that matter) for the full email.
2023-02-11 11:07:58 +00:00
"enum": [
"legacy",
"curved",
"square",
"ascii",
"ascii-large"
],
Add ui.graph.style into config schema
2023-01-31 06:21:49 +00:00
"default": "legacy"
}
}
},
cli: add ui.log-word-wrap option Unlike Mercurial, this isn't a template keyword/function, but a config knob. Exposing graph_width to templater wouldn't be easy, and I don't think it's better to handle terminal wrapping in template. I'm not sure if patch content should be wrapped, so this option only applies to the template output for now. Closes #1043
2023-03-05 04:10:02 +00:00
"log-word-wrap": {
"type": "boolean",
"description": "Whether to wrap log template output",
"default": false
},
Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
"editor": {
"type": "string",
"description": "Editor to use for commands that involve editing text"
},
"diff-editor": {
"type": "string",
"description": "Editor tool to use for editing diffs",
"default": "meld"
},
"merge-editor": {
"type": "string",
"description": "Tool to use for resolving three-way merges. Behavior for a given tool name can be configured in merge-tools.TOOL tables"
}
}
},
"colors": {
"type": "object",
Update schema for [colors] to allow either string or table values
2023-01-31 06:56:19 +00:00
"description": "Mapping from jj formatter labels to colors",
"definitions": {
"colors": {
"enum": [
formatter: allow using "default" terminal color The "default" color resets the terminal color to default.
2023-04-08 06:25:30 +00:00
"default",
Update schema for [colors] to allow either string or table values
2023-01-31 06:56:19 +00:00
"black",
"red",
"green",
"yellow",
"blue",
"magenta",
"cyan",
"white",
"bright black",
"bright red",
"bright green",
"bright yellow",
"bright blue",
"bright magenta",
"bright cyan",
"bright white"
]
},
"basicFormatterLabels": {
"enum": [
"description",
"change_id",
"commit_id",
"author",
"committer",
"working_copies",
"current_working_copy",
"branches",
"tags",
"git_refs",
"is_git_head",
"divergent",
Templater: label hidden commits (aka abandoned commits) Looks like "change_id normal" + color. Picture for `jj obslog`: https://user-images.githubusercontent.com/4123047/230708271-4108cf5f-255d-419e-bd3e-fc97dc8b8660.png This should also be occasionally be useful for e.g. `jj log commit_id`. I also considered the wording `(Was change_id)` or `change_id (old)`, `change_id (obs)`.
2023-04-08 01:28:16 +00:00
"hidden",
templater: add `root` keyword Similar to other boolean flags, such as "working_copy" or "empty". We could test something like `"0000000000000000000000000000000000000000".contains(commit_id)` like I did for myself, but first of all this is ugly, and secondly the root commit id is not guaranteed to be 40 zeroes as custom backend implementations could have some other root.
2023-08-15 13:18:56 +00:00
"conflict",
"root"
Update schema for [colors] to allow either string or table values
2023-01-31 06:56:19 +00:00
]
}
},
"propertyNames": {
"oneOf": [
config: add and parse `ui.log_author_format` for use in the default template Supported values are, - `none` for no author information, - `full` for both the name and email, - `name` for just the name, - `username` for username part of the email, - (default) `email` (or any other gibberish for that matter) for the full email.
2023-02-11 11:07:58 +00:00
{
"$ref": "#/properties/colors/definitions/basicFormatterLabels"
},
{
"type": "string"
}
Update schema for [colors] to allow either string or table values
2023-01-31 06:56:19 +00:00
]
},
Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
"additionalProperties": {
Update schema for [colors] to allow either string or table values
2023-01-31 06:56:19 +00:00
"description": "A color profile for the given formatter label. Either a bare color name used as the foreground color or a table describing color and formatting",
"oneOf": [
{
"$ref": "#/properties/colors/definitions/colors"
},
{
"type": "object",
"properties": {
config: add and parse `ui.log_author_format` for use in the default template Supported values are, - `none` for no author information, - `full` for both the name and email, - `name` for just the name, - `username` for username part of the email, - (default) `email` (or any other gibberish for that matter) for the full email.
2023-02-11 11:07:58 +00:00
"fg": {
"$ref": "#/properties/colors/definitions/colors"
},
"bg": {
"$ref": "#/properties/colors/definitions/colors"
},
Update schema for [colors] to allow either string or table values
2023-01-31 06:56:19 +00:00
"bold": {
"type": "boolean"
},
"underline": {
"type": "boolean"
}
}
}
Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
]
}
},
Add ui.unique-prefixes and git.auto-local-branch to config schema
2023-01-31 08:50:30 +00:00
"git": {
"type": "object",
"description": "Settings for git behavior (when using git backend)",
"properties": {
"auto-local-branch": {
"type": "boolean",
"description": "Whether jj creates a local branch with the same name when it imports a remote-tracking branch from git. See https://github.com/martinvonz/jj/blob/main/docs/config.md#automatic-local-branch-creation",
"default": true
git fetch: accept several remotes The "--remote" option can be repeated, and the "git.fetch" key is now a list.
2023-02-02 18:31:11 +00:00
},
git: add config to disable abandoning of unreachable commits Some users prefer to have commits not get abandoned when importing refs. This adds a config option for that. Closes #2504.
2023-11-05 05:15:41 +00:00
"abandon-unreachable-commits": {
"type": "boolean",
"description": "Whether jj should abandon commits that became unreachable in Git.",
"default": true
},
config: Rename `push.branch-prefix` option to `git.push-branch-prefix` This is for consistency with other `git.` options. See also https://github.com/martinvonz/jj/pull/1962#discussion_r1282605185
2023-08-07 22:36:39 +00:00
"push-branch-prefix": {
"type": "string",
"description": "Prefix used when pushing a change ID as a new branch",
"default": "push-"
},
git fetch: accept several remotes The "--remote" option can be repeated, and the "git.fetch" key is now a list.
2023-02-02 18:31:11 +00:00
"fetch": {
"description": "The remote(s) from which commits are fetched",
"default": "origin",
"oneOf": [
{
"type": "string"
},
{
"type": "array",
"items": {
"type": "string"
}
}
]
config: add schema for git.push configuration entry
2023-02-02 23:20:07 +00:00
},
"push": {
"type": "string",
"description": "The remote to which commits are pushed",
"default": "origin"
Add ui.unique-prefixes and git.auto-local-branch to config schema
2023-01-31 08:50:30 +00:00
}
}
},
Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
"merge-tools": {
"type": "object",
"description": "Tables of custom options to pass to the given merge tool (selected in ui.merge-editor)",
"additionalProperties": {
"type": "object",
"properties": {
"program": {
"type": "string"
},
cli: add option to generate textual diff by external command This is basic implementation. There's no config knob to enable the external diff command by default. It reuses the merge-tools table because that's how external diff/merge commands are currently configured. We might want to reorganize them in #1285. If you run "jj diff --tool meld", GUI diff will open and jj will wait for meld to quit. This also applies to "jj log -p". The "diff --tool gui" behavior is somewhat useful, but "log -p --tool gui" wouldn't. We might want some flag to mark the tool output can't be streamed. Another thing to consider is tools that can't generate directory diffs. Git executes ext-diff tool per file, but we don't. Difftastic can compare directories, and doing that should be more efficient since diffs can be computed in parallel (at the expense of unsorted output.) Closes #1886
2023-08-02 03:12:11 +00:00
"diff-args": {
"type": "array",
"items": {
"type": "string"
}
},
config: add merge-tools.<name>.edit-args to schema
2023-02-06 10:56:41 +00:00
"edit-args": {
"type": "array",
"items": {
"type": "string"
}
},
Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
"merge-args": {
"type": "array",
"items": {
"type": "string"
}
},
"merge-tool-edits-conflict-markers": {
"type": "boolean",
"description": "Whether to populate the output file with conflict markers before starting the merge tool. See https://github.com/martinvonz/jj/blob/main/docs/config.md#editing-conflict-markers-with-a-tool-or-a-text-editor",
"default": false
}
}
}
},
cli: rename `ui.default-revset` to `revsets.log` I plan to add `revsets.short-prefixes` and `revsets.immutable` soon, and I think `[revsets]` seems like reasonable place to put them. It seems consistent with our `[templates]` section. However, it also suffers from the same problem as that section, which is that the difference between `[templates]` and `[template-aliases]` is not clear. We can decide about about templates and revsets later.
2023-05-11 06:26:23 +00:00
"revsets": {
"type": "object",
"description": "Revset expressions used by various commands",
"properties": {
"log": {
"type": "string",
"description": "Default set of revisions to show when no explicit revset is given for jj log and similar commands",
cli: redefine default log revset using `immutable_heads()` I think most users who change the set of immutable heads away from `trunk() | tags()` are going to also want to change the default log revset to include the newly mutable commit and to exclude the newly immutable commits. So let's update the default log revset to use `immutable_heads()` instead. `test_templater` changed because we have overridden the set of immutable commits there so `jj log` now includes the remote branch.
2023-09-06 05:05:17 +00:00
"default": "@ | ancestors(immutable_heads().., 2) | heads(immutable_heads())"
cli: allow resolving shorter ids within a configured revset This adds a config called `revsets.short-prefixes`, which lets the user specify a revset in which to disambiguate otherwise ambiguous change/commit ids. It defaults to the value of `revsets.log`. I made it so you can disable the feature by setting `revsets.short-prefixes = ""`. I don't like that the default value (using `revsets.log`) cannot be configured explicitly by the user. That will be addressed if we decide to merge the `[revsets]` and `[revset-aliases]` sections some day.
2023-05-06 00:12:08 +00:00
},
"short-prefixes": {
"type": "string",
"description": "Revisions to give shorter change and commit IDs to",
"default": "<revsets.log>"
cli: rename `ui.default-revset` to `revsets.log` I plan to add `revsets.short-prefixes` and `revsets.immutable` soon, and I think `[revsets]` seems like reasonable place to put them. It seems consistent with our `[templates]` section. However, it also suffers from the same problem as that section, which is that the difference between `[templates]` and `[template-aliases]` is not clear. We can decide about about templates and revsets later.
2023-05-11 06:26:23 +00:00
}
},
"additionalProperties": {
"type": "string"
}
},
Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
"revset-aliases": {
"type": "object",
"description": "Custom symbols/function aliases that can used in revset expressions",
cli: make set of immutable commits configurable This adds a new `revset-aliases.immutable_heads()s` config for defining the set of immutable commits. The set is defined as the configured revset, as well as its ancestors, and the root commit commit (even if the configured set is empty). This patch also adds enforcement of the config where we already had checks preventing rewrite of the root commit. The working-copy commit is implicitly assumed to be writable in most cases. Specifically, we won't prevent amending the working copy even if the user includes it in the config but we do prevent `jj edit @` in that case. That seems good enough to me. Maybe we should emit a warning when the working copy is in the set of immutable commits. Maybe we should add support for something more like [Mercurial's phases](https://wiki.mercurial-scm.org/Phases), which is propagated on push and pull. There's already some affordance for that in the view object's `public_heads` field. However, this is simpler, especially since we can't propagate the phase to Git remotes, and seems like a good start. Also, it lets you say that commits authored by other users are immutable, for example. For now, the functionality is in the CLI library. I'm not sure if we want to move it into the library crate. I'm leaning towards letting library users do whatever they want without being restricted by immutable commits. I do think we should move the functionality into a future `ui-lib` or `ui-util` crate. That crate would have most of the functionality in the current `cli_util` module (but in a non-CLI-specific form).
2023-09-02 02:12:01 +00:00
"properties": {
"immutable_heads()": {
"type": "string",
"description": "Revisions to consider immutable. Ancestors of these are also considered immutable. The root commit is always considered immutable.",
"default": "trunk() | tags()"
}
},
Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
"additionalProperties": {
"type": "string"
}
},
cli: load [template-aliases] section and pass around aliases table
2023-02-12 08:53:09 +00:00
"template-aliases": {
"type": "object",
"description": "Custom symbols/function aliases that can used in templates",
"additionalProperties": {
"type": "string"
}
},
config: rename [alias] to [aliases], still supporting old name The name of the [alias] section is inconsistent with other table-valued sections ([revset-aliases], [colors], [merge-tools]), so let's rename it. For comparison, `Cargo.toml` also uses plural names (e.g. `[dependencies]`).
2023-01-26 22:26:05 +00:00
"aliases": {
Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
"type": "object",
"description": "Custom subcommand aliases to be supported by the jj command",
"additionalProperties": {
"type": "array",
"items": {
"type": "string"
}
}
working_copy: don't snapshot new files larger than 1MiB by default
2023-06-28 22:10:19 +00:00
},
"snapshot": {
"type": "object",
"description": "Parameters governing automatic capture of files into the working copy commit",
"properties": {
"max-new-file-size": {
cli: make set of immutable commits configurable This adds a new `revset-aliases.immutable_heads()s` config for defining the set of immutable commits. The set is defined as the configured revset, as well as its ancestors, and the root commit commit (even if the configured set is empty). This patch also adds enforcement of the config where we already had checks preventing rewrite of the root commit. The working-copy commit is implicitly assumed to be writable in most cases. Specifically, we won't prevent amending the working copy even if the user includes it in the config but we do prevent `jj edit @` in that case. That seems good enough to me. Maybe we should emit a warning when the working copy is in the set of immutable commits. Maybe we should add support for something more like [Mercurial's phases](https://wiki.mercurial-scm.org/Phases), which is propagated on push and pull. There's already some affordance for that in the view object's `public_heads` field. However, this is simpler, especially since we can't propagate the phase to Git remotes, and seems like a good start. Also, it lets you say that commits authored by other users are immutable, for example. For now, the functionality is in the CLI library. I'm not sure if we want to move it into the library crate. I'm leaning towards letting library users do whatever they want without being restricted by immutable commits. I do think we should move the functionality into a future `ui-lib` or `ui-util` crate. That crate would have most of the functionality in the current `cli_util` module (but in a non-CLI-specific form).
2023-09-02 02:12:01 +00:00
"type": [
"integer",
"string"
],
working_copy: don't snapshot new files larger than 1MiB by default
2023-06-28 22:10:19 +00:00
"description": "New files with a size in bytes above this threshold are not snapshotted, unless the threshold is 0",
settings: support human-readable byte sizes for max-new-file-size
2023-08-11 19:52:58 +00:00
"default": "1MiB"
working_copy: don't snapshot new files larger than 1MiB by default
2023-06-28 22:10:19 +00:00
}
}
Define config TOML/JSON schema Can be used with tools like taplo-lsp to show hints & validation in editors/IDEs. Won't apply automatically to config files until it's submitted to schemastore.org, but in the meantime it can be used via a schema directive (https://taplo.tamasfe.dev/configuration/directives.html#the-schema-directive) or other manual config mechanism. Context in #879.
2023-01-01 06:29:33 +00:00
}
}
cli: make set of immutable commits configurable This adds a new `revset-aliases.immutable_heads()s` config for defining the set of immutable commits. The set is defined as the configured revset, as well as its ancestors, and the root commit commit (even if the configured set is empty). This patch also adds enforcement of the config where we already had checks preventing rewrite of the root commit. The working-copy commit is implicitly assumed to be writable in most cases. Specifically, we won't prevent amending the working copy even if the user includes it in the config but we do prevent `jj edit @` in that case. That seems good enough to me. Maybe we should emit a warning when the working copy is in the set of immutable commits. Maybe we should add support for something more like [Mercurial's phases](https://wiki.mercurial-scm.org/Phases), which is propagated on push and pull. There's already some affordance for that in the view object's `public_heads` field. However, this is simpler, especially since we can't propagate the phase to Git remotes, and seems like a good start. Also, it lets you say that commits authored by other users are immutable, for example. For now, the functionality is in the CLI library. I'm not sure if we want to move it into the library crate. I'm leaning towards letting library users do whatever they want without being restricted by immutable commits. I do think we should move the functionality into a future `ui-lib` or `ui-util` crate. That crate would have most of the functionality in the current `cli_util` module (but in a non-CLI-specific form).
2023-09-02 02:12:01 +00:00
}
Reference in a new issue Copy permalink