--affected could not determine changed files. All tasks will

Error message

--affected could not determine changed files. All tasks will run. Check your git fetch depth.

What it means

For `turbo run --affected`, the builder asks the SCM layer (git) for the set of changed files relative to the base. If git reports an invalid/failed change set (crates/turborepo-lib/src/run/builder.rs:1251-1271), turbo cannot know which tasks are affected, warns, and degrades gracefully: with a package scope it keeps that scope; otherwise every task in the graph runs.

Source

Thrown at crates/turborepo-lib/src/run/builder.rs:1260

                    affected_entrypoints.retain(|task| scoped_tasks.contains(task));
                }
                let selected_packages = affected_entrypoints
                    .iter()
                    .map(|task| PackageName::from(task.package()))
                    .collect();
                let affected_entrypoints =
                    super::task_filter::expand_with_siblings(&engine, affected_entrypoints);
                Ok((
                    engine.retain_filtered_tasks(&affected_entrypoints),
                    Some(selected_packages),
                ))
            }
            Err(e) => {
                tracing::warn!(
                    error = ?e,
                    "SCM returned invalid change set; skipping task-level filtering"
                );
                turborepo_log::warn(
                    turborepo_log::Source::turbo(turborepo_log::Subsystem::Scm),
                    "--affected could not determine changed files. All tasks will run. Check your \
                     git fetch depth.",
                )
                .field("error", format!("{e:?}"))
                .emit();
                let Some(package_scope) = package_scope else {
                    return Ok((engine, None));
                };
                let scoped_tasks = engine.task_ids_for_packages(package_scope);
                let scoped_tasks = super::task_filter::expand_with_siblings(&engine, scoped_tasks);
                Ok((engine.retain_filtered_tasks(&scoped_tasks), None))
            }
        }
    }

    fn task_entrypoint_exclusions<'a>(
        &self,

View on GitHub (pinned to f9245100cf)

Solutions

Deepen history so the merge-base exists: git fetch --unshallow (or git fetch --deepen=100 / --depth=N large enough) before turbo run --affected.
Make sure the default/base branch is fetched and origin/HEAD resolves: git remote set-head origin --auto; fetch the base branch explicitly.
Sanity-check locally: `git merge-base HEAD origin/<default-branch>` must print a commit, not fail.
In CI, set the base explicitly (e.g. --affected vs the configured base/SCM options) or use a full clone for affected runs.

Example fix

# before: shallow checkout, affected can never resolve
- uses: actions/checkout@v4        # depth: 1 by default
- run: pnpm turbo run build --affected

# after: fetch enough history for the merge base
- uses: actions/checkout@v4
  with:
    fetch-depth: 0        # or a deep enough number
- run: pnpm turbo run build --affected

Defensive patterns

Strategy: validation

Validate before calling

#!/usr/bin/env bash
# --affected requires a resolvable merge base
DEFAULT_BRANCH="${DEFAULT_BRANCH:-origin/main}"
git fetch --deepen=200 "$DEFAULT_BRANCH" 2>/dev/null || git fetch --unshallow
if ! git merge-base HEAD "$DEFAULT_BRANCH" >/dev/null 2>&1; then
  echo "merge base with $DEFAULT_BRANCH unavailable — --affected would run all tasks" >&2
  exit 1
fi
turbo run build --affected

Prevention

Use fetch-depth: 0 (or a sufficiently deep fetch) in CI checkouts that run --affected.
Ensure origin/HEAD points at the real default branch (git remote set-head origin --auto).
Smoke-test `git merge-base HEAD origin/<default>` locally before relying on --affected in pipelines.

When it happens

Trigger: git fails to compute changed files: shallow clones where the merge-base commit is missing (typical CI checkout with fetch-depth: 1), a missing/incorrect default branch (origin/HEAD unset or base branch not fetched), or a corrupt git index. The raw error is attached as a structured 'error' field next to the warning.

Common situations: GitHub Actions actions/checkout with default depth 1, GitLab shallow clones, CI checkouts that never fetch the target branch, and monorepos after force-pushes where the expected merge-base doesn't exist locally. Symptom: --affected always runs everything.

Related errors

AI-assisted analysis of vercel/turborepo@f9245100cf (2026-08-17). Data as JSON: /api/errors/93030eb15017fe28. Report an issue: GitHub.