mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2024-12-29 07:59:00 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
jj/cli/tests/test_immutable_commits.rs

218 lines
10 KiB
Rust
Raw Normal View History

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
// Copyright 2023 The Jujutsu Authors
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// https://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
use crate::common::TestEnvironment;
#[test]
fn test_rewrite_immutable_generic() {
let test_env = TestEnvironment::default();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
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
let repo_path = test_env.env_root().join("repo");
std::fs::write(repo_path.join("file"), "a").unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["describe", "-m=a"]);
test_env.jj_cmd_ok(&repo_path, &["new", "-m=b"]);
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
std::fs::write(repo_path.join("file"), "b").unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["branch", "create", "main"]);
test_env.jj_cmd_ok(&repo_path, &["new", "main-", "-m=c"]);
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
std::fs::write(repo_path.join("file"), "c").unwrap();
let stdout = test_env.jj_cmd_success(&repo_path, &["log"]);
insta::assert_snapshot!(stdout, @r###"
cli: show timestamp in local timezone and without millis and offset As discussed in #2900, the milliseconds are rarely useful, and it can be confusing with different timezones because it makes harder to compare timestamps. I added an environment variable to control the timestamp in a cross-platform way. I didn't document because it exists only for tests (like `JJ_RANDOMNESS_SEED`). Closes #2900
2024-02-12 07:26:19 +00:00
@ mzvwutvl test.user@example.com 2001-02-03 08:05:12 78ebd449
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
│ c
cli: show timestamp in local timezone and without millis and offset As discussed in #2900, the milliseconds are rarely useful, and it can be confusing with different timezones because it makes harder to compare timestamps. I added an environment variable to control the timestamp in a cross-platform way. I didn't document because it exists only for tests (like `JJ_RANDOMNESS_SEED`). Closes #2900
2024-02-12 07:26:19 +00:00
│ ◉ kkmpptxz test.user@example.com 2001-02-03 08:05:10 main c8d4c7ca
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
├─╯ b
cli: show timestamp in local timezone and without millis and offset As discussed in #2900, the milliseconds are rarely useful, and it can be confusing with different timezones because it makes harder to compare timestamps. I added an environment variable to control the timestamp in a cross-platform way. I didn't document because it exists only for tests (like `JJ_RANDOMNESS_SEED`). Closes #2900
2024-02-12 07:26:19 +00:00
◉ qpvuntsm test.user@example.com 2001-02-03 08:05:08 46a8dc51
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
│ a
◉ zzzzzzzz root() 00000000
"###);
// Cannot rewrite a commit in the configured set
test_env.add_config(r#"revset-aliases."immutable_heads()" = "main""#);
let stderr = test_env.jj_cmd_failure(&repo_path, &["edit", "main"]);
insta::assert_snapshot!(stderr, @r###"
Error: Commit c8d4c7ca95d0 is immutable
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// Cannot rewrite an ancestor of the configured set
let stderr = test_env.jj_cmd_failure(&repo_path, &["edit", "main-"]);
insta::assert_snapshot!(stderr, @r###"
Error: Commit 46a8dc5175be is immutable
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// Cannot rewrite the root commit even with an empty set of immutable commits
test_env.add_config(r#"revset-aliases."immutable_heads()" = "none()""#);
let stderr = test_env.jj_cmd_failure(&repo_path, &["edit", "root()"]);
insta::assert_snapshot!(stderr, @r###"
immutable commits: remove the hint if trying to edit the root commit The hint is a bit misleading in this case. I also changed the message slightly.
2023-10-29 03:36:57 +00:00
Error: The root commit 000000000000 is immutable
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
"###);
// Error if we redefine immutable_heads() with an argument
test_env.add_config(r#"revset-aliases."immutable_heads(foo)" = "none()""#);
let stderr = test_env.jj_cmd_failure(&repo_path, &["edit", "root()"]);
insta::assert_snapshot!(stderr, @r###"
cli: check invalid declaration of immutable_heads() alias earlier I just wanted to remove CommandError from parse_immutable_expression(), which will be called from the templater, but the new error message looks also better.
2024-03-14 02:59:34 +00:00
Error: The `revset-aliases.immutable_heads()` function must be declared without arguments
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
"###);
// ... even if we also update the built-in call sites
test_env.add_config(r#"revsets.short-prefixes = "immutable_heads(root())""#);
let stderr = test_env.jj_cmd_failure(&repo_path, &["edit", "root()"]);
insta::assert_snapshot!(stderr, @r###"
cli: check invalid declaration of immutable_heads() alias earlier I just wanted to remove CommandError from parse_immutable_expression(), which will be called from the templater, but the new error message looks also better.
2024-03-14 02:59:34 +00:00
Error: The `revset-aliases.immutable_heads()` function must be declared without arguments
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
"###);
}
#[test]
fn test_rewrite_immutable_commands() {
let test_env = TestEnvironment::default();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["init", "repo", "--git"]);
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
let repo_path = test_env.env_root().join("repo");
std::fs::write(repo_path.join("file"), "a").unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["describe", "-m=a"]);
test_env.jj_cmd_ok(&repo_path, &["new", "-m=b"]);
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
std::fs::write(repo_path.join("file"), "b").unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["new", "@-", "-m=c"]);
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
std::fs::write(repo_path.join("file"), "c").unwrap();
tests: replace jj_cmd_success() involving mutation to allow stderr output
2023-10-10 11:59:18 +00:00
test_env.jj_cmd_ok(&repo_path, &["new", "all:visible_heads()", "-m=merge"]);
test_env.jj_cmd_ok(&repo_path, &["branch", "create", "main"]);
test_env.jj_cmd_ok(&repo_path, &["new", "description(b)"]);
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
test_env.add_config(r#"revset-aliases."immutable_heads()" = "main""#);
cli: change default log revset to not include all tagged heads The default immutable_heads() includes tags(), which makes sense, but computing heads(tags()) can be expensive because the tags() set is usually sparse. For example, "jj bench revset 'heads(tags())'" took 157ms in my linux stable mirror. We can of course optimize the heads evaluation by using bit set or segmented index, but the query includes many historical heads if the repository has per-release branches, which are uninteresting anyway. So, this patch replaces heads(immutable_heads()) with trunk(). The reason we include heads(immutable_heads()) is to mitigate the following problem. Suppose trunk() is the branch to be based off, I think using trunk() here is pretty good. ``` A B *---*----* trunk() ⊆ immutable_heads() \ * C ``` https://github.com/martinvonz/jj/pull/2247#discussion_r1335078879
2024-02-19 14:20:13 +00:00
test_env.add_config(r#"revset-aliases."trunk()" = "main""#);
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
cli: change default log revset to not include all tagged heads The default immutable_heads() includes tags(), which makes sense, but computing heads(tags()) can be expensive because the tags() set is usually sparse. For example, "jj bench revset 'heads(tags())'" took 157ms in my linux stable mirror. We can of course optimize the heads evaluation by using bit set or segmented index, but the query includes many historical heads if the repository has per-release branches, which are uninteresting anyway. So, this patch replaces heads(immutable_heads()) with trunk(). The reason we include heads(immutable_heads()) is to mitigate the following problem. Suppose trunk() is the branch to be based off, I think using trunk() here is pretty good. ``` A B *---*----* trunk() ⊆ immutable_heads() \ * C ``` https://github.com/martinvonz/jj/pull/2247#discussion_r1335078879
2024-02-19 14:20:13 +00:00
// Log shows mutable commits, their parents, and trunk() by default
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
let stdout = test_env.jj_cmd_success(&repo_path, &["log"]);
insta::assert_snapshot!(stdout, @r###"
cli: show timestamp in local timezone and without millis and offset As discussed in #2900, the milliseconds are rarely useful, and it can be confusing with different timezones because it makes harder to compare timestamps. I added an environment variable to control the timestamp in a cross-platform way. I didn't document because it exists only for tests (like `JJ_RANDOMNESS_SEED`). Closes #2900
2024-02-12 07:26:19 +00:00
@ yqosqzyt test.user@example.com 2001-02-03 08:05:13 3f89addf
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
│ (empty) (no description set)
cli: show timestamp in local timezone and without millis and offset As discussed in #2900, the milliseconds are rarely useful, and it can be confusing with different timezones because it makes harder to compare timestamps. I added an environment variable to control the timestamp in a cross-platform way. I didn't document because it exists only for tests (like `JJ_RANDOMNESS_SEED`). Closes #2900
2024-02-12 07:26:19 +00:00
│ ◉ mzvwutvl test.user@example.com 2001-02-03 08:05:11 main 3d14df18 conflict
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
╭─┤ (empty) merge
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
│ │
│ ~
│
cli: show timestamp in local timezone and without millis and offset As discussed in #2900, the milliseconds are rarely useful, and it can be confusing with different timezones because it makes harder to compare timestamps. I added an environment variable to control the timestamp in a cross-platform way. I didn't document because it exists only for tests (like `JJ_RANDOMNESS_SEED`). Closes #2900
2024-02-12 07:26:19 +00:00
◉ kkmpptxz test.user@example.com 2001-02-03 08:05:10 c8d4c7ca
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
│ b
~
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
"###);
// abandon
let stderr = test_env.jj_cmd_failure(&repo_path, &["abandon", "main"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// chmod
let stderr = test_env.jj_cmd_failure(&repo_path, &["chmod", "-r=main", "x", "file"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// describe
let stderr = test_env.jj_cmd_failure(&repo_path, &["describe", "main"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// diffedit
let stderr = test_env.jj_cmd_failure(&repo_path, &["diffedit", "-r=main"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// edit
let stderr = test_env.jj_cmd_failure(&repo_path, &["edit", "main"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// move --from
let stderr = test_env.jj_cmd_failure(&repo_path, &["move", "--from=main"]);
insta::assert_snapshot!(stderr, @r###"
cli: add convenient methods to print hint or warning with default headings The lowercase "warning: " is unified to "Warning: " as it is the jj's convention afaik. The _default() suffix could be dropped from these methods, but it's probably better to break the existing codebase for the moment. Otherwise, the caller might do writeln!(ui.warning(), "Warning: ..").
2024-03-24 06:24:32 +00:00
Warning: `jj move` is deprecated; use `jj squash` instead, which is equivalent
Warning: `jj move` will be removed in a future version, and this will be a hard error
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// move --to
let stderr = test_env.jj_cmd_failure(&repo_path, &["move", "--to=main"]);
insta::assert_snapshot!(stderr, @r###"
cli: add convenient methods to print hint or warning with default headings The lowercase "warning: " is unified to "Warning: " as it is the jj's convention afaik. The _default() suffix could be dropped from these methods, but it's probably better to break the existing codebase for the moment. Otherwise, the caller might do writeln!(ui.warning(), "Warning: ..").
2024-03-24 06:24:32 +00:00
Warning: `jj move` is deprecated; use `jj squash` instead, which is equivalent
Warning: `jj move` will be removed in a future version, and this will be a hard error
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
cli new: have `--before/--after` respect immutable commits I wasn't very careful to make the function pretty; I'm planning to refactor it anyway as part of implementing `rebase --before` and `rebase --after`.
2023-10-30 02:56:42 +00:00
// new --insert-before
let stderr = test_env.jj_cmd_failure(&repo_path, &["new", "--insert-before", "main"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
cli new: have `--before/--after` respect immutable commits I wasn't very careful to make the function pretty; I'm planning to refactor it anyway as part of implementing `rebase --before` and `rebase --after`.
2023-10-30 02:56:42 +00:00
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// new --insert-after parent_of_main
let stderr = test_env.jj_cmd_failure(&repo_path, &["new", "--insert-after", "description(b)"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
cli new: have `--before/--after` respect immutable commits I wasn't very careful to make the function pretty; I'm planning to refactor it anyway as part of implementing `rebase --before` and `rebase --after`.
2023-10-30 02:56:42 +00:00
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
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
// rebase -s
let stderr = test_env.jj_cmd_failure(&repo_path, &["rebase", "-s=main", "-d=@"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// rebase -b
let stderr = test_env.jj_cmd_failure(&repo_path, &["rebase", "-b=main", "-d=@"]);
insta::assert_snapshot!(stderr, @r###"
Error: Commit 6e11f430f297 is immutable
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// rebase -r
let stderr = test_env.jj_cmd_failure(&repo_path, &["rebase", "-r=main", "-d=@"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// resolve
let stderr = test_env.jj_cmd_failure(&repo_path, &["resolve", "-r=description(merge)", "file"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// restore -c
let stderr = test_env.jj_cmd_failure(&repo_path, &["restore", "-c=main"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// restore --to
let stderr = test_env.jj_cmd_failure(&repo_path, &["restore", "--to=main"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// split
let stderr = test_env.jj_cmd_failure(&repo_path, &["split", "-r=main"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// squash
squash: fail on merge commits before failing on immutable commits This is just a little step towards reusing the helper I just extracted from `jj move`. I had to update `test_immutable_commits.rs` because it would otherwise fail because of the merge rather than failing because of the immutable commit.
2024-03-11 00:48:05 +00:00
let stderr = test_env.jj_cmd_failure(&repo_path, &["squash", "-r=description(b)"]);
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
insta::assert_snapshot!(stderr, @r###"
squash: fail on merge commits before failing on immutable commits This is just a little step towards reusing the helper I just extracted from `jj move`. I had to update `test_immutable_commits.rs` because it would otherwise fail because of the merge rather than failing because of the immutable commit.
2024-03-11 00:48:05 +00:00
Error: Commit c8d4c7ca95d0 is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// unsquash
let stderr = test_env.jj_cmd_failure(&repo_path, &["unsquash", "-r=main"]);
insta::assert_snapshot!(stderr, @r###"
git_backend: write trees involved in conflict in git commit header We haven't used custom Git commit headers for two main reasons: 1. I don't want commits created by jj to be different from any other commits. I don't want Git projects to get annoyed by such commit and reject them. 2. I've been concerned that tools don't know how to handle such headers, perhaps even resulting in crashes. The first argument doesn't apply to commits with conflicts because such commits would never be accepted by a project whether or not they use custom commit headers. The second argument is less relevant for conflicted commits because most tools will be confused by such commits anyway. Storing conflict information in commit headers means that we can transfer them via the regular Git wire protocol. We already include the tree objects nested inside the root-level tree, so they will also be transferred. So, let's start by writing the information redundantly to the commit header and to the existing storage. That way we can roll it back if we realize there's a problem with using commit headers.
2024-03-09 16:55:52 +00:00
Error: Commit 3d14df18607e is immutable
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
Hint: Configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
}
Reference in a new issue Copy permalink