ok/jj
1
0
Fork 0
forked from mirrors/jj
Code Pull requests Activity
jj/cli/tests/test_immutable_commits.rs

334 lines
16 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: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
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###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
@ mzvwutvl test.user@example.com 2001-02-03 08:05:12 7adb43e8
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
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
│ ○ kkmpptxz test.user@example.com 2001-02-03 08:05:10 main 72e1b68c
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
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
○ qpvuntsm test.user@example.com 2001-02-03 08:05:08 b84b821b
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
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
◆ zzzzzzzz root() 00000000
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
"###);
// 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###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 72e1b68cbcf2 is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
// Cannot rewrite an ancestor of the configured set
let stderr = test_env.jj_cmd_failure(&repo_path, &["edit", "main-"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit b84b821b8a2b is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
// 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
"###);
cli: add better error message when immutable_heads() cannot be resolved
2024-04-01 16:01:12 +00:00
// Error mutating the repo if immutable_heads() uses a ref that can't be
// resolved
test_env.add_config(r#"revset-aliases."immutable_heads()" = "branch_that_does_not_exist""#);
let stderr = test_env.jj_cmd_failure(&repo_path, &["new", "main"]);
insta::assert_snapshot!(stderr, @r###"
Config error: Invalid `revset-aliases.immutable_heads()`
Caused by: Revision "branch_that_does_not_exist" doesn't exist
For help, see https://github.com/martinvonz/jj/blob/main/docs/config.md.
"###);
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
// Can use --ignore-immutable to override
test_env.add_config(r#"revset-aliases."immutable_heads()" = "main""#);
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["--ignore-immutable", "edit", "main"]);
insta::assert_snapshot!(stdout, @r###"
"###);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Working copy now at: kkmpptxz 72e1b68c main | b
Parent commit : qpvuntsm b84b821b a
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Added 0 files, modified 1 files, removed 0 files
"###);
// ... but not the root commit
let stderr = test_env.jj_cmd_failure(&repo_path, &["--ignore-immutable", "edit", "root()"]);
insta::assert_snapshot!(stderr, @r###"
Error: The root commit 000000000000 is immutable
"###);
cli: add better error message when immutable_heads() cannot be resolved
2024-04-01 16:01:12 +00:00
// Mutating the repo works if ref is wrapped in present()
test_env.add_config(
r#"revset-aliases."immutable_heads()" = "present(branch_that_does_not_exist)""#,
);
let (stdout, stderr) = test_env.jj_cmd_ok(&repo_path, &["new", "main"]);
insta::assert_snapshot!(stdout, @r###"
"###);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Working copy now at: wqnwkozp fc921593 (empty) (no description set)
Parent commit : kkmpptxz 72e1b68c main | b
cli: add better error message when immutable_heads() cannot be resolved
2024-04-01 16:01:12 +00:00
"###);
revset, templater: implement arity-based alias overloading Still alias function shadows builtin function (of any arity) by name. This allows to detect argument error as such, but might be a bit inconvenient if user wants to overload heads() for example. If needed, maybe we can add some config/revset syntax to import builtin function to alias namespace. The functions table is keyed by name, not by (name, arity) pair. That's mainly because std collections require keys to be Borrow, and a pair of borrowed values is incompatible with owned pair. Another reason is it makes easy to look up overloads by name. Alias overloading could also be achieved by adding default parameters, but that will complicate the implementation a bit more, and can't prevent shadowing of 0-ary immutable_heads(). Closes #2966
2024-06-05 13:29:10 +00:00
// immutable_heads() of different arity doesn't shadow the 0-ary one
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(foo)" = "none()""#);
let stderr = test_env.jj_cmd_failure(&repo_path, &["edit", "root()"]);
insta::assert_snapshot!(stderr, @r###"
revset, templater: implement arity-based alias overloading Still alias function shadows builtin function (of any arity) by name. This allows to detect argument error as such, but might be a bit inconvenient if user wants to overload heads() for example. If needed, maybe we can add some config/revset syntax to import builtin function to alias namespace. The functions table is keyed by name, not by (name, arity) pair. That's mainly because std collections require keys to be Borrow, and a pair of borrowed values is incompatible with owned pair. Another reason is it makes easy to look up overloads by name. Alias overloading could also be achieved by adding default parameters, but that will complicate the implementation a bit more, and can't prevent shadowing of 0-ary immutable_heads(). Closes #2966
2024-06-05 13:29:10 +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
"###);
}
cli: create new wc_commit when wc_commit become immuable
2024-04-29 20:08:35 +00:00
#[test]
fn test_new_wc_commit_when_wc_immutable() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init"]);
test_env.jj_cmd_ok(test_env.env_root(), &["branch", "create", "main"]);
test_env.add_config(r#"revset-aliases."immutable_heads()" = "main""#);
test_env.jj_cmd_ok(test_env.env_root(), &["new", "-m=a"]);
let (_, stderr) = test_env.jj_cmd_ok(test_env.env_root(), &["branch", "set", "main"]);
insta::assert_snapshot!(stderr, @r###"
cli: show commit summary at end of "branch set" For the same reason as the previous commit. Created and moved stats are printed separately because it's unusual to do both within one "branch set" invocation.
2024-07-04 23:40:53 +00:00
Moved 1 branches to kkmpptxz a164195b main | (empty) a
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Warning: The working-copy commit in workspace 'default' became immutable, so a new commit has been created on top of it.
Working copy now at: zsuskuln ef5fa85b (empty) (no description set)
Parent commit : kkmpptxz a164195b main | (empty) a
cli: create new wc_commit when wc_commit become immuable
2024-04-29 20:08:35 +00:00
"###);
}
#[test]
fn test_immutable_heads_set_to_working_copy() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init"]);
test_env.jj_cmd_ok(test_env.env_root(), &["branch", "create", "main"]);
test_env.add_config(r#"revset-aliases."immutable_heads()" = "@""#);
let (_, stderr) = test_env.jj_cmd_ok(test_env.env_root(), &["new", "-m=a"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Warning: The working-copy commit in workspace 'default' became immutable, so a new commit has been created on top of it.
Working copy now at: pmmvwywv 7278b2d8 (empty) (no description set)
Parent commit : kkmpptxz a713ef56 (empty) a
cli: create new wc_commit when wc_commit become immuable
2024-04-29 20:08:35 +00:00
"###);
}
#[test]
fn test_new_wc_commit_when_wc_immutable_multi_workspace() {
let test_env = TestEnvironment::default();
test: update workspace path in test case This test case was creating "workspace1" as a sub-directory of the default workspace, which seems like a mistake.
2024-07-17 22:14:50 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
let repo_path = test_env.env_root().join("repo");
test_env.jj_cmd_ok(&repo_path, &["branch", "create", "main"]);
cli: create new wc_commit when wc_commit become immuable
2024-04-29 20:08:35 +00:00
test_env.add_config(r#"revset-aliases."immutable_heads()" = "main""#);
test: update workspace path in test case This test case was creating "workspace1" as a sub-directory of the default workspace, which seems like a mistake.
2024-07-17 22:14:50 +00:00
test_env.jj_cmd_ok(&repo_path, &["new", "-m=a"]);
test_env.jj_cmd_ok(&repo_path, &["workspace", "add", "../workspace1"]);
cli: create new wc_commit when wc_commit become immuable
2024-04-29 20:08:35 +00:00
let workspace1_envroot = test_env.env_root().join("workspace1");
test: update workspace path in test case This test case was creating "workspace1" as a sub-directory of the default workspace, which seems like a mistake.
2024-07-17 22:14:50 +00:00
test_env.jj_cmd_ok(&workspace1_envroot, &["edit", "default@"]);
let (_, stderr) = test_env.jj_cmd_ok(&repo_path, &["branch", "set", "main"]);
cli: create new wc_commit when wc_commit become immuable
2024-04-29 20:08:35 +00:00
insta::assert_snapshot!(stderr, @r###"
test: update workspace path in test case This test case was creating "workspace1" as a sub-directory of the default workspace, which seems like a mistake.
2024-07-17 22:14:50 +00:00
Moved 1 branches to kkmpptxz 7796c4df main | (empty) a
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Warning: The working-copy commit in workspace 'default' became immutable, so a new commit has been created on top of it.
Warning: The working-copy commit in workspace 'workspace1' became immutable, so a new commit has been created on top of it.
test: update workspace path in test case This test case was creating "workspace1" as a sub-directory of the default workspace, which seems like a mistake.
2024-07-17 22:14:50 +00:00
Working copy now at: royxmykx 896465c4 (empty) (no description set)
Parent commit : kkmpptxz 7796c4df main | (empty) a
cli: create new wc_commit when wc_commit become immuable
2024-04-29 20:08:35 +00:00
"###);
test: update workspace path in test case This test case was creating "workspace1" as a sub-directory of the default workspace, which seems like a mistake.
2024-07-17 22:14:50 +00:00
test_env.jj_cmd_ok(&workspace1_envroot, &["workspace", "update-stale"]);
let (stdout, _) = test_env.jj_cmd_ok(&workspace1_envroot, &["log", "--no-graph"]);
cli: create new wc_commit when wc_commit become immuable
2024-04-29 20:08:35 +00:00
insta::assert_snapshot!(stdout, @r###"
test: update workspace path in test case This test case was creating "workspace1" as a sub-directory of the default workspace, which seems like a mistake.
2024-07-17 22:14:50 +00:00
nppvrztz test.user@example.com 2001-02-03 08:05:11 workspace1@ ee0671fd
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
(empty) (no description set)
test: update workspace path in test case This test case was creating "workspace1" as a sub-directory of the default workspace, which seems like a mistake.
2024-07-17 22:14:50 +00:00
royxmykx test.user@example.com 2001-02-03 08:05:12 default@ 896465c4
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
(empty) (no description set)
test: update workspace path in test case This test case was creating "workspace1" as a sub-directory of the default workspace, which seems like a mistake.
2024-07-17 22:14:50 +00:00
kkmpptxz test.user@example.com 2001-02-03 08:05:09 main 7796c4df
(empty) a
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
zzzzzzzz root() 00000000
"###);
cli: create new wc_commit when wc_commit become immuable
2024-04-29 20:08:35 +00:00
}
cli: make set of immutable commits configurable This adds a new `revset-aliases.immutable_heads()s` config for defining the set of immutable commits. The set is defined as the configured revset, as well as its ancestors, and the root commit commit (even if the configured set is empty). This patch also adds enforcement of the config where we already had checks preventing rewrite of the root commit. The working-copy commit is implicitly assumed to be writable in most cases. Specifically, we won't prevent amending the working copy even if the user includes it in the config but we do prevent `jj edit @` in that case. That seems good enough to me. Maybe we should emit a warning when the working copy is in the set of immutable commits. Maybe we should add support for something more like [Mercurial's phases](https://wiki.mercurial-scm.org/Phases), which is propagated on push and pull. There's already some affordance for that in the view object's `public_heads` field. However, this is simpler, especially since we can't propagate the phase to Git remotes, and seems like a good start. Also, it lets you say that commits authored by other users are immutable, for example. For now, the functionality is in the CLI library. I'm not sure if we want to move it into the library crate. I'm leaning towards letting library users do whatever they want without being restricted by immutable commits. I do think we should move the functionality into a future `ui-lib` or `ui-util` crate. That crate would have most of the functionality in the current `cli_util` module (but in a non-CLI-specific form).
2023-09-02 02:12:01 +00:00
#[test]
fn test_rewrite_immutable_commands() {
let test_env = TestEnvironment::default();
tests: avoid deprecated `jj init --git/--git-repo` I left the instances in `test_init_command.rs` alone since they're about testing `jj init`.
2024-05-17 19:49:25 +00:00
test_env.jj_cmd_ok(test_env.env_root(), &["git", "init", "repo"]);
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"]);
Refuse to split an empty commit with `jj split`. Rationale: The user may be confused by the empty diff in the diff editor tool if they accidentally run `jj split` on a wrong (empty) commit.
2024-05-10 14:44:49 +00:00
// Create another file to make sure the merge commit isn't empty (to satisfy `jj
// split`) and still has a conflict (to satisfy `jj resolve`).
std::fs::write(repo_path.join("file2"), "merged").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", "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###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
@ yqosqzyt test.user@example.com 2001-02-03 08:05:13 65147295
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)
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
│ ◆ mzvwutvl test.user@example.com 2001-02-03 08:05:12 main 1d5af877 conflict
Refuse to split an empty commit with `jj split`. Rationale: The user may be confused by the empty diff in the diff editor tool if they accidentally run `jj split` on a wrong (empty) commit.
2024-05-10 14:44:49 +00:00
╭─┤ 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
│ │
│ ~
│
Enable the new graph nodes by default. It's been tested in various places now, so this is probably mature enough to be the default.
2024-07-15 22:20:10 +00:00
◆ kkmpptxz test.user@example.com 2001-02-03 08:05:10 72e1b68c
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###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
// chmod
feat: Create a `file` command containing `print` and `chmod` - rearrange the files involved to be more clear about structure - deprecate existing `jj cat` and `jj chmod`
2024-06-14 14:34:17 +00:00
let stderr = test_env.jj_cmd_failure(&repo_path, &["file", "chmod", "-r=main", "x", "file"]);
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###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
// describe
let stderr = test_env.jj_cmd_failure(&repo_path, &["describe", "main"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
// diffedit
let stderr = test_env.jj_cmd_failure(&repo_path, &["diffedit", "-r=main"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
// edit
let stderr = test_env.jj_cmd_failure(&repo_path, &["edit", "main"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
// 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
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
// 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
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
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###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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-after parent_of_main
let stderr = test_env.jj_cmd_failure(&repo_path, &["new", "--insert-after", "description(b)"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
Implement jj parallelize Parallelize revisions by making them siblings Running `jj parallelize 1::2` will transform the history like this: ```text 3 | 3 2 / \ | -> 1 2 1 \ / | 0 0 ``` Each of the target revisions is rebased onto the parents of the root(s) of the target revset (not to be confused with the repo root). The children of the head(s) of the target revset are rebased onto the target revisions. The target revset is the union of the REVISIONS arguments. The target revset being parallelized must satisfy several conditions, otherwise the command will fail. 1. The heads of the target revset must not have different children. 2. The roots of the target revset must not have different parents. 3. The parents of all target revisions except the roots must also be parallelized. This means that the target revisions must be connected.
2024-03-31 12:46:55 +00:00
// parallelize
let stderr = test_env.jj_cmd_failure(&repo_path, &["parallelize", "description(b)", "main"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or configure the set of immutable commits via `revset-aliases.immutable_heads()`.
Implement jj parallelize Parallelize revisions by making them siblings Running `jj parallelize 1::2` will transform the history like this: ```text 3 | 3 2 / \ | -> 1 2 1 \ / | 0 0 ``` Each of the target revisions is rebased onto the parents of the root(s) of the target revset (not to be confused with the repo root). The children of the head(s) of the target revset are rebased onto the target revisions. The target revset is the union of the REVISIONS arguments. The target revset being parallelized must satisfy several conditions, otherwise the command will fail. 1. The heads of the target revset must not have different children. 2. The roots of the target revset must not have different parents. 3. The parents of all target revisions except the roots must also be parallelized. This means that the target revisions must be connected.
2024-03-31 12:46:55 +00:00
"###);
cli: make set of immutable commits configurable This adds a new `revset-aliases.immutable_heads()s` config for defining the set of immutable commits. The set is defined as the configured revset, as well as its ancestors, and the root commit commit (even if the configured set is empty). This patch also adds enforcement of the config where we already had checks preventing rewrite of the root commit. The working-copy commit is implicitly assumed to be writable in most cases. Specifically, we won't prevent amending the working copy even if the user includes it in the config but we do prevent `jj edit @` in that case. That seems good enough to me. Maybe we should emit a warning when the working copy is in the set of immutable commits. Maybe we should add support for something more like [Mercurial's phases](https://wiki.mercurial-scm.org/Phases), which is propagated on push and pull. There's already some affordance for that in the view object's `public_heads` field. However, this is simpler, especially since we can't propagate the phase to Git remotes, and seems like a good start. Also, it lets you say that commits authored by other users are immutable, for example. For now, the functionality is in the CLI library. I'm not sure if we want to move it into the library crate. I'm leaning towards letting library users do whatever they want without being restricted by immutable commits. I do think we should move the functionality into a future `ui-lib` or `ui-util` crate. That crate would have most of the functionality in the current `cli_util` module (but in a non-CLI-specific form).
2023-09-02 02:12:01 +00:00
// rebase -s
let stderr = test_env.jj_cmd_failure(&repo_path, &["rebase", "-s=main", "-d=@"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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 -b
let stderr = test_env.jj_cmd_failure(&repo_path, &["rebase", "-b=main", "-d=@"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 77cee210cbf5 is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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 -r
let stderr = test_env.jj_cmd_failure(&repo_path, &["rebase", "-r=main", "-d=@"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
// resolve
let stderr = test_env.jj_cmd_failure(&repo_path, &["resolve", "-r=description(merge)", "file"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
// restore -c
let stderr = test_env.jj_cmd_failure(&repo_path, &["restore", "-c=main"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
// restore --to
let stderr = test_env.jj_cmd_failure(&repo_path, &["restore", "--to=main"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
// split
let stderr = test_env.jj_cmd_failure(&repo_path, &["split", "-r=main"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
squash: add test that immutable commits are respected for `--from/--into`
2024-04-28 16:58:46 +00:00
// squash -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
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###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 72e1b68cbcf2 is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
squash: add test that immutable commits are respected for `--from/--into`
2024-04-28 16:58:46 +00:00
// squash --from
let stderr = test_env.jj_cmd_failure(&repo_path, &["squash", "--from=main"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
squash: add test that immutable commits are respected for `--from/--into`
2024-04-28 16:58:46 +00:00
Hint: Pass `--ignore-immutable` or configure the set of immutable commits via `revset-aliases.immutable_heads()`.
"###);
// squash --into
let stderr = test_env.jj_cmd_failure(&repo_path, &["squash", "--into=main"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
squash: add test that immutable commits are respected for `--from/--into`
2024-04-28 16:58:46 +00:00
Hint: Pass `--ignore-immutable` or 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
// unsquash
let stderr = test_env.jj_cmd_failure(&repo_path, &["unsquash", "-r=main"]);
insta::assert_snapshot!(stderr, @r###"
commit_builder: reset author timestamp on discardable commits It's common to create empty working-copy commits while using jj, and currently the author timestamp for a commit is only set when it is first created. If you create an empty commit, then don't work on a repo for a few days, and then start working on a new feature without abandoning the working-copy commit, the author timestamp will remain as the time the commit was created rather than being updated to the time that work began or finished. This commit changes the behavior so that discardable commits (empty commits with no description) by the current user have their author timestamps reset when they are rewritten, meaning that the author timestamp will become finalized whenever a commit is given a description or becomes non-empty.
2024-06-23 22:20:33 +00:00
Error: Commit 1d5af877b8bb is immutable
cli: add global `--ignore-immutable` Closes #3576
2024-04-25 23:56:03 +00:00
Hint: Pass `--ignore-immutable` or 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
"###);
}
Copy permalink