partial pulls are not supported: apply the complete setup…

Error message

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

What it means

The dotfile sync `apply` operation only supports applying the entire tracked setup: it replays a full snapshot from history onto the working tree. If the caller supplies PATH arguments (a partial apply), mise rejects the request up front because incremental application is not implemented. The full setup must be applied with no path filters.

Solutions

Run the apply/pull command without PATH arguments to apply the complete setup.
If you only want one file, apply fully and then revert the other files, or use the history show/checkout tooling if it supports single-file views.
Update any wrapper scripts to stop passing paths to apply.
Request or watch for partial-apply support upstream if this is a frequent need.

Example fix

// before
mise dotfiles pull ~/.zshrc
Error: partial pulls are not supported...

// after
mise dotfiles pull

Defensive patterns

Strategy: validation

Validate before calling

if !path_args.is_empty() {
  eprintln!("apply does not accept PATH arguments; run it with none to apply the full setup");
}

Type guard

fn apply_request_is_full(req: &ApplyRequest) -> bool {
  req.paths.is_empty()
}

Try / catch

match result {
  Err(e) if e.to_string().contains("partial pulls are not supported") => {
    // fall back to a full apply and selectively revert afterwards
  }
  other => other?,
}

Prevention

Invoke dotfile pull/apply without path arguments.
Strip user-supplied paths in wrapper scripts before calling apply.
Use history show/checkout flows for per-file inspection instead.

When it happens

Trigger: Running the dotfile pull/apply command with path arguments, e.g. `mise dotfiles pull ~/.bashrc`, which reaches `apply_locked` with a non-empty `req.paths`.

Common situations: Users expecting git-pull-like selective restores of a single dotfile; shell scripts forwarding user-supplied paths into the apply command.

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@533346cc37 (2026-09-17). Data as JSON: /api/errors/77fdd60a0f5916aa. Report an issue: GitHub.

Appendix: source

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

}

/// Applies a prepared synchronization while the caller holds the sync lock.
pub(crate) async fn apply_locked(
    store: &Store,
    tracked: &TrackedSet,
    req: &ApplyRequest,
) -> Result<ApplyOutcome> {
    apply_locked_with_scope(store, tracked, req, None).await
}

pub(crate) async fn apply_locked_with_scope(
    store: &Store,
    tracked: &TrackedSet,
    req: &ApplyRequest,
    mut operation_scope: Option<OperationScope>,
) -> Result<ApplyOutcome> {
    if !req.paths.is_empty() {
        bail!("partial pulls are not supported: apply the complete setup without PATH arguments");
    }
    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 533346cc37)