jdx/mise · error

[dotfiles]." / ": block content may not contain its own…

Error message

[dotfiles]."{}/{}": block content may not contain its own marker lines

What it means

Block edits wrap their content in `>>> mise:<id> >>>` / `<<< mise:<id> <<<` marker lines so mise can find and replace the region on reapply. If the block's own content contains a line matching one of its markers, the written file could not be parsed back into a single managed region, so `desired_content` refuses up front instead of corrupting the target on a later apply. This check runs in `desired_content`, which is called by check, apply, print_diffs, and apply_dry_run_to_string.

Solutions

1. Remove the marker-like lines from the block content.
2. Change the entry's `id` so its markers no longer match the content.
3. Set a different `comment` style if the collision comes from comment formatting.
4. Move the pre-managed region out of the block and let mise manage it with its own separate entry.

Example fix

# before
[dotfiles."~/.zshrc".nested]
id = "nested"
block = " >>> mise:nested >>>\necho hi"

# after
[dotfiles."~/.zshrc".nested]
id = "nested"
block = "echo hi"

let content = e.block.as_deref().unwrap_or("");
for pat in [format!(">>> mise:{} >>>", id), format!("<<< mise:{} <<<", id)] {
    if content.lines().any(|l| l.contains(&pat)) {
        return Err(format!("block content contains its own marker {pat}"));
    }
}

When it happens

Trigger: A block entry's `block` (or sourced file) content includes a line like `>>> mise:myid >>>` or `<<< mise:myid <<<` matching its own id/comment style. `desired_content` iterates both marker patterns and bails at src/system/edits.rs:490.

Common situations: Users copy an existing mise-managed region into another entry's content, nest dotfile configs that re-include their own markers, or generate templated content that embeds markers.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

• destination variants require an explicit source when any…
• destination variants with inline content are not supported
• [dotfiles]." ": mode symlink-each requires a directory…
• files
• " ". : block and source are mutually exclusive, ignoring…

AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17). Data as JSON: /api/errors/7a9505428c7dea0b. Report an issue: GitHub.

Appendix: source

Thrown at src/system/edits.rs:490

            &raw,
            config.bootstrap_tera_ctx(&req.origin.config),
        )
        .map_err(|err| {
            eyre::eyre!(
                "[dotfiles].\"{}/{}\": failed to render template: {err}",
                req.path_raw,
                req.id
            )
        })?
    } else {
        raw
    };
    let content = content.trim_end_matches('\n').to_string();
    // a block containing its own marker lines would write a file that can't
    // be parsed back — refuse up front instead of corrupting on reapply
    for pat in [format!(">>> mise:{id} >>>"), format!("<<< mise:{id} <<<")] {
        if content.lines().any(|l| is_marker_line(l, &pat, comment)) {
            bail!(
                "[dotfiles].\"{}/{}\": block content may not contain its own marker lines",
                req.path_raw,
                req.id
            );
        }
    }
    Ok(Some(content))
}

/// Current state of one edit on this machine.
///
/// Note: comparing a template block against existing markers requires
/// rendering it, so this can run the template engine — including `exec()` —
/// from `mise dot status`. That's the same trust model as `[env]`
/// templates. Rendering only happens once every render-free outcome (symlink
/// target, missing file, absent or corrupted markers) has been ruled out,
/// and `--dry-run` skips template rendering entirely (see [`apply`]).
pub(crate) fn check(config: &Config, req: &EditRequest) -> Result<FileState> {

View on GitHub (pinned to 533346cc37)