cli: support --file option in config commands by vaghinak-vardanyan · Pull Request #10005 · jj-vcs/jj

vaghinak-vardanyan · 2026-08-18T13:43:27Z

Allow targeting a specific config file path with --file in
jj config {edit,set,unset}.

This enables explicit targeting of specific configuration files (such
as files in conf.d/ or custom files loaded via --config-file) and
avoids interactive prompts when multiple config files exist.

The --file option validates that the target path is a recognized jj
configuration location to prevent creating untracked or arbitrary files.

Additionally this changes the behavior of the jj config {edit,set,unset} --user
to target primary config file instead of an interactive window to choose between
that and conf.d/*.toml

Fixes #9541

Checklist

If applicable:

I have updated CHANGELOG.md
I have updated the documentation (README.md, docs/, demos/)
I have updated the config schema (cli/src/config-schema.json)
I have added/updated tests to cover my changes
I fully understand the code that I am submitting (what it does,
how it works, how it's organized), including any code drafted by an LLM.
For any prose generated by an LLM, I have proof-read and copy-edited with
an eye towards deleting anything that is irrelevant, clarifying anything
that is confusing, and adding details that are relevant. This includes,
for example, commit descriptions, PR descriptions, and code comments.

vaghinak-vardanyan · 2026-08-18T14:13:47Z

cc @josephlou5 (as discussed on #9541) . As I don't have access yet to add reviewers.

Note: Added myself to docs/paid_contributors.md in #10006

josephlou5

Could you also update docs/config.md with some text about this flag?

joyously · 2026-08-18T15:48:51Z

The "unattended automation" part seems dangerous, when other discussions were focused on the security of the config files.
Especially now that there have been AI models that have escaped their testing sandbox, is it smart to enable this sort of thing?

josephlou5 · 2026-08-18T15:57:42Z

Does there also need to be any more handling for my comment #9541 (comment)? It would be nice if jj config edit/set/unset --user targeted the global <config_root>/.config/jj/config.toml file, and an explicit --file <config_root>/.config/jj/conf.d/blah.toml would target that specific file.

vaghinak-vardanyan · 2026-08-19T12:31:53Z

Could you also update docs/config.md with some text about this flag?

Done.

vaghinak-vardanyan · 2026-08-19T12:34:08Z

Does there also need to be any more handling for my comment #9541 (comment)? It would be nice if jj config edit/set/unset --user targeted the global <config_root>/.config/jj/config.toml file, and an explicit --file <config_root>/.config/jj/conf.d/blah.toml would target that specific file.

I agree that now as --file exists, it makes sense to restrict --user to the primary config file. Although I would like to change it in a separate commit/CL to basically keep the commits clean, like this one adds a new feature, another one changes a behavior. What do you think?

vaghinak-vardanyan · 2026-08-19T12:36:01Z

The "unattended automation" part seems dangerous, when other discussions were focused on the security of the config files. Especially now that there have been AI models that have escaped their testing sandbox, is it smart to enable this sort of thing?

Just to clarify, the interactive prompt was only there to disambiguate between multiple config files, not as a security gate. Commands like jj config set --repo (and git config) were running non-interactively, and any process running jj could already edit the config files on disk directly anyway.

I also added path validation so --file can only target valid jj config locations. I've updated the wording in the changelog and commit message to avoid confusion!

josephlou5

Btw you can resolve comment threads once you've addressed them: https://docs.jj-vcs.dev/latest/contributing/#code-reviews

josephlou5 · 2026-08-20T00:02:30Z

+            }
        }
+
+        // 5. Check system config paths (/etc/jj/config.toml or files in /etc/jj/conf.d)


Does this mean jj config edit --file /etc/jj/config.toml will work?

Yes. As long as the user/process has write permissions for /etc/jj/ (e.g. running under sudo or as root), jj config {edit,set,unset} --file /etc/jj/config.toml will work and target it as ConfigSource::System.

If run without write permissions, it will fail with a standard permission denied error.

AFAIK this is new behavior. Should it be documented?

There's also a question of whether it should be possible, as I think these system files should usually be provided rather than available to be edited. Obviously if you have permission you can do whatever, but Jujutsu thus far has simply said "system configuration is loaded from here" and that was the end of the story. I guess there isn't a huge reason to not do this, but just saying it felt a little surprising to me :)

If we keep this, I think it should be documented.

Thanks for the context! I don't feel strongly either way. My thinking was just consistency: since --file allows targeting specific config files, supporting system config paths felt natural. I've updated the docs accordingly.
I am also okay to remove if we eventually consider that. Let me know what you think.

josephlou5 · 2026-08-20T00:04:12Z

 /// See `jj config edit` if you'd like to immediately edit a file.
 #[derive(clap::Args, Clone, Debug)]
+#[group(id = "config_level", multiple = false, required = true)]
 pub struct ConfigPathArgs {


Nit: Maybe add a regular // comment explaining why the common ConfigTargetArgs can't be reused here? (Because this command doesn't accept --file.)

josephlou5 · 2026-08-20T00:11:53Z

Although I would like to change it in a separate commit/CL to basically keep the commits clean, like this one adds a new feature, another one changes a behavior. What do you think?

Yes, that sounds good. You can keep it in this PR if you'd like (and I would recommend that too).

yuja · 2026-08-20T03:35:52Z

+    /// Target the workspace-level config
+    #[arg(long)]
+    workspace: bool,
+}


Can you leave the original ConfigLevelArgs unmodified? I don't think jj config list should support --file=PATH either.

Thanks for the feedback. Yeah, I agree. I guess I misunderstood how list worked on the first pass. I've reverted ConfigLevelArgs, and introduced ConfigTargetArgs specifically for the modifying commands (edit, set, unset). Could you please have another look on that?

Allow targeting a specific config file path with `--file` in `jj config {edit,set,unset}`. This enables explicit targeting of specific configuration files (such as files in `conf.d/` or custom files loaded via `--config-file`) and avoids interactive prompts when multiple config files exist. The `--file` option validates that the target path is a recognized `jj` configuration location to prevent creating untracked or arbitrary files. Fixes jj-vcs#9541

When modifying user configuration (`jj config {edit,set,unset} --user`), always target the primary user configuration file (`~/.config/jj/config.toml` or `~/.jjconfig.toml`) rather than prompting when drop-in files exist in `conf.d/`. Specific drop-in files in `conf.d/` can now be targeted explicitly with the `--file` option. Fixes jj-vcs#9541

yuja · 2026-08-31T12:12:58Z

+#[test]
+fn test_config_set_file_with_existing_scopes() -> TestResult {
+    let mut test_env = TestEnvironment::default();
+    let conf_d = test_env.config_path().parent().unwrap().join("conf.d");


nit: test_env.env_root().join("conf.d") ?

yuja · 2026-08-31T12:14:07Z

+    // Using JJ_CONFIG allows targeting any custom file with --file
+    let env_file = test_env.env_root().join("from_env.toml");
+    std::fs::write(&env_file, "")?;
+    let output = work_dir.run_jj_with(|cmd| {
+        cmd.env("JJ_CONFIG", &env_file);
+        cmd.args([
+            "config",
+            "set",
+            "--file",
+            env_file.to_str().unwrap(),
+            "env-key",
+            "env-val",
+        ])
+    });
+    insta::assert_snapshot!(output, @"");
+    assert_eq!(
+        std::fs::read_to_string(&env_file)?,
+        "env-key = \"env-val\"\n"
+    );


nit: This seems redundant because JJ_CONFIG is set globally by the test runner.

yuja · 2026-08-31T12:19:00Z

+    // Using global --config-file allows targeting any custom file with --file
+    let custom_file = test_env.env_root().join("outside.toml");
+    std::fs::write(&custom_file, "")?;
+    let output = work_dir.run_jj([
+        "--config-file",
+        custom_file.to_str().unwrap(),
+        "config",
+        "set",
+        "--file",
+        custom_file.to_str().unwrap(),
+        "outside-key",
+        "outside-val",
+    ]);
+    insta::assert_snapshot!(output, @"");
+    assert_eq!(
+        std::fs::read_to_string(&custom_file)?,
+        "outside-key = \"outside-val\"\n"
+    );


nit: Do you think this behavior is useful? If not, can you update the comment to note that it can be removed if necessary?

yuja · 2026-08-31T12:20:00Z

+    Hint: Valid config locations include user configs (`~/.config/jj/config.toml` or `conf.d/*.toml`), repo/workspace configs, or files loaded with the global flag `--config-file <PATH>`.
+    [EOF]
+    [exit status: 1]
+    ");


nit: Can you add a test for a valid relative path?

yuja · 2026-08-31T12:22:18Z

+fn test_config_set_user_with_conf_d() -> TestResult {
+    let mut test_env = TestEnvironment::default();
+    let config_dir = test_env.config_path().parent().unwrap();
+    let config_file = config_dir.join("config.toml");
+    let conf_d = config_dir.join("conf.d");
+    std::fs::create_dir_all(&conf_d)?;
+    std::fs::write(&config_file, "foo = 'from_config'\n")?;
+    std::fs::write(conf_d.join("work.toml"), "bar = 'from_work'\n")?;
+    let user_config_path = join_paths([&config_file, &conf_d])?;
+    test_env.set_config_path(&user_config_path);
+
+    // Setting with --user targets config.toml directly without prompting
+    let output = test_env.run_jj_in(".", ["config", "set", "--user", "foo", "updated_foo"]);
+    insta::assert_snapshot!(output, @"");
+    assert_eq!(
+        std::fs::read_to_string(&config_file)?,
+        "foo = \"updated_foo\"\n"
+    );
+    assert_eq!(
+        std::fs::read_to_string(conf_d.join("work.toml"))?,
+        "bar = 'from_work'\n"
+    );
+
+    Ok(())
+}
+
+#[test]
+fn test_config_set_user_targets_first_file_when_only_conf_d_exists() -> TestResult {
+    let mut test_env = TestEnvironment::default();
+    let config_dir = test_env.config_path().parent().unwrap();
+    let config_file = config_dir.join("config.toml");
+    let conf_d = config_dir.join("conf.d");
+    std::fs::create_dir_all(&conf_d)?;
+    std::fs::write(conf_d.join("01_work.toml"), "bar = 'from_work'\n")?;
+    std::fs::write(conf_d.join("02_home.toml"), "baz = 'from_home'\n")?;
+    let user_config_path = join_paths([&config_file, &conf_d])?;
+    test_env.set_config_path(&user_config_path);
+
+    // config.toml does not exist
+    assert!(!config_file.exists());
+
+    // Setting with --user targets the first file in conf.d
+    let output = test_env.run_jj_in(".", ["config", "set", "--user", "foo", "new_foo"]);
+    insta::assert_snapshot!(output, @"");
+    assert!(!config_file.exists());
+    assert_eq!(
+        std::fs::read_to_string(conf_d.join("01_work.toml"))?,
+        "bar = 'from_work'\nfoo = \"new_foo\"\n"
+    );
+    assert_eq!(
+        std::fs::read_to_string(conf_d.join("02_home.toml"))?,
+        "baz = 'from_home'\n"
+    );
+
+    Ok(())
+}


These tests look redundant. We already have jj config set/edit with multiple files.

vaghinak-vardanyan requested a review from a team as a code owner August 18, 2026 13:43

PhilipMetzger reviewed Aug 18, 2026

View reviewed changes

Comment thread cli/src/commands/config/list.rs

josephlou5 reviewed Aug 18, 2026

View reviewed changes

Comment thread cli/src/commands/config/mod.rs Outdated

josephlou5 reviewed Aug 18, 2026

View reviewed changes

Comment thread cli/tests/cli-reference@.md.snap Outdated

vaghinak-vardanyan force-pushed the config-file-option branch 3 times, most recently from bed312f to d36171e Compare August 19, 2026 11:37

josephlou5 reviewed Aug 20, 2026

View reviewed changes

yuja reviewed Aug 20, 2026

View reviewed changes

vaghinak-vardanyan force-pushed the config-file-option branch 2 times, most recently from a521699 to 8e8696f Compare August 24, 2026 00:20

josephlou5 reviewed Aug 24, 2026

View reviewed changes

Comment thread docs/config.md

vaghinak-vardanyan force-pushed the config-file-option branch from 8e8696f to cc38b45 Compare August 24, 2026 10:29

vaghinak-vardanyan commented Aug 24, 2026

View reviewed changes

Comment thread CHANGELOG.md Outdated

vaghinak-vardanyan force-pushed the config-file-option branch 2 times, most recently from 9476eb6 to 7f8386a Compare August 24, 2026 13:30

yuja reviewed Aug 25, 2026

View reviewed changes

Comment thread cli/src/commands/config/mod.rs Outdated

Comment thread cli/src/config.rs Outdated

Comment thread cli/src/config.rs Outdated

Comment thread cli/src/config.rs Outdated

Comment thread cli/src/config.rs Outdated

vaghinak-vardanyan force-pushed the config-file-option branch from 7f8386a to 32395a5 Compare August 29, 2026 09:44

josephlou5 reviewed Aug 30, 2026

View reviewed changes

Comment thread CHANGELOG.md Outdated

Comment thread CHANGELOG.md Outdated

vaghinak-vardanyan force-pushed the config-file-option branch 2 times, most recently from 069d007 to f5f836b Compare August 30, 2026 07:07

yuja reviewed Aug 30, 2026

View reviewed changes

Comment thread cli/src/config.rs Outdated

Comment thread cli/src/config.rs Outdated

Comment thread cli/tests/test_config_command.rs Outdated

Comment thread cli/src/config.rs Outdated

vaghinak-vardanyan force-pushed the config-file-option branch 2 times, most recently from 8b19193 to 1a93ab7 Compare August 31, 2026 06:57

vaghinak-vardanyan force-pushed the config-file-option branch from 1a93ab7 to be0bdbc Compare August 31, 2026 07:04

yuja approved these changes Aug 31, 2026

View reviewed changes

Uh oh!

Conversation

vaghinak-vardanyan commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Uh oh!

vaghinak-vardanyan commented Aug 18, 2026

Uh oh!

Uh oh!

josephlou5 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

joyously commented Aug 18, 2026

Uh oh!

Uh oh!

josephlou5 commented Aug 18, 2026

Uh oh!

vaghinak-vardanyan commented Aug 19, 2026

Uh oh!

vaghinak-vardanyan commented Aug 19, 2026

Uh oh!

vaghinak-vardanyan commented Aug 19, 2026

Uh oh!

josephlou5 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

josephlou5 commented Aug 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

vaghinak-vardanyan commented Aug 18, 2026 •

edited

Loading