partial pulls are not supported: apply the complete setup wi

Error message

partial pulls are not supported: apply the complete setup without PATH arguments

What it means

The dotfile-sync `apply` operation is implemented as an all-or-nothing pull: it applies the complete tracked setup under a sync lock. Partial application (a subset of files selected via PATH arguments) is not supported by this code path, so any request carrying non-empty `paths` is rejected up front. This keeps apply/revert state consistent — reverting a partial pull would be ambiguous.

Source

Thrown at src/system/history/sync/apply.rs:96

struct Step {
    pending: PendingApplication,
    path: PathBuf,
    group: String,
    exists: bool,
    /// The complete live object when planned, verified before each write.
    before: Option<Object>,
    permissions: Option<std::fs::Permissions>,
    before_mode: Option<u32>,
    desired_mode: Option<u32>,
}

pub(crate) async fn apply(
    store: &Store,
    tracked: &TrackedSet,
    req: &ApplyRequest,
) -> Result<ApplyOutcome> {
    if !req.paths.is_empty() {
        bail!("partial pulls are not supported: apply the complete setup without PATH arguments");
    }
    let _sync_lock = run::lock(store)?;
    let repo = store
        .repo()
        .ok_or_else(|| eyre::eyre!("applying requires git"))?;
    let state_dir = store.state_dir();
    let planned_head = repo.ref_oid(crate::system::history::shadow::HistoryRepo::HISTORY_REF)?;
    let incoming = run::incoming_tracking(repo, tracked)?;
    let tracked = &incoming;
    // Metadata changes must advance the same complete Git tree after live
    // application. They cannot be reduced to this machine's selected paths.
    let mut inventory_tree = run::incoming_repository_tree(repo, tracked)?;
    let mut status = run::read_status(state_dir)?;
    if req.automatic && status.application_failure.is_some() {
        return Ok(ApplyOutcome {
            held: status.pending_applications.len().max(1),
            ..Default::default()
        });

View on GitHub (pinned to afd2eddd3a)

Solutions

Run the pull without path arguments to apply the complete setup: `mise dot pull`.
If you only want one file updated, apply everything, then manually restore the other files if needed.
Use per-file diff/revert commands (`mise dot diff <path>`) to inspect individual files instead of partial apply.
Coordinate with teammates: pull fully, then commit only the desired changes if the setup is version-controlled.

Example fix

// before: partial pull request
ApplyRequest { paths: vec!["~/.zshrc".into()], .. }
// after: full apply
ApplyRequest { paths: vec![], .. }

Defensive patterns

Strategy: validation

Validate before calling

if !req_paths.is_empty() {
    eprintln!("partial pulls unsupported; drop path arguments to pull everything");
}

Try / catch

match sync::apply(&store, &tracked, &req).await {
    Ok(outcome) => report(outcome),
    Err(e) if e.to_string().contains("partial pulls are not supported") => {
        eprintln!("rerun `mise dot pull` without path arguments");
    }
    Err(e) => return Err(e),
}

Prevention

Never pass path filters to dotfile pull/apply
Use `mise dot diff <path>` to inspect files instead of partial apply
Document in team scripts that pulls are all-or-nothing

When it happens

Trigger: Calling `apply` (the pull/sync apply path) with an `ApplyRequest` whose `paths` vector is non-empty, e.g. `mise dot pull path/to/file` style usage routed to this function.

Common situations: A user tries to pull just one changed dotfile to avoid touching the rest; a script passes path filters from a generic sync wrapper; muscle memory from `git checkout <path>` style partial operations.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/77fdd60a0f5916aa. Report an issue: GitHub.