rust-lang/cargo · info · anyhow::Error

no path segments on url

Error message

no path segments on url

What it means

Inside `github_fast_path` (src/sources/git/utils.rs:1586) Cargo parses the GitHub repository URL and calls `Url::path_segments()`, which returns `None` for URLs that cannot have a base / have no hierarchical path (e.g. `data:` / opaque / non-standard schemes that the `url` crate treats as cannot-be-a-base). This error is essentially defensive: the function's own doc comment states it 'should never cause an actual failure', and the sole caller (`fetch()` at src/sources/git/utils.rs:1035) catches `Err`, logs it at `debug!`, and falls back to the normal fetch path. In practice it is swallowed, not surfaced to the user.

Source

Thrown at src/sources/git/utils.rs:1650

                // either. (This ensures that we always attempt to fetch the
                // commit directly even if we can't reach the GitHub API.)
                if let Some(oid) = rev_to_oid(rev) {
                    debug!("github fast path is already a full commit hash {rev}");
                    return Ok(FastPathRev::NeedsFetch(oid));
                }
                rev
            } else {
                debug!("can't use github fast path with `rev = \"{}\"`", rev);
                return Ok(FastPathRev::Indeterminate);
            }
        }
    };

    // This expects GitHub urls in the form `github.com/user/repo` and nothing
    // else
    let mut pieces = url
        .path_segments()
        .ok_or_else(|| anyhow!("no path segments on url"))?;
    let username = pieces
        .next()
        .ok_or_else(|| anyhow!("couldn't find username"))?;
    let repository = pieces
        .next()
        .ok_or_else(|| anyhow!("couldn't find repository name"))?;
    if pieces.next().is_some() {
        anyhow::bail!("too many segments on URL");
    }

    // Trim off the `.git` from the repository, if present, since that's
    // optional for GitHub and won't work when we try to use the API as well.
    let repository = repository.strip_suffix(".git").unwrap_or(repository);

    let url = format!(
        "https://api.github.com/repos/{}/{}/commits/{}",
        username, repository, github_branch_name,
    );

View on GitHub (pinned to 0e07a15537)

Solutions

1. No user action required — this is a swallowed fast-path miss; Cargo proceeds to a normal fetch.
2. If you see it flooding debug logs, correct the git dependency URL in `Cargo.toml` / `[source]` mapping to a well-formed `https://github.com/user/repo` form.
3. Check `.cargo/config.toml` `[url]` / `insteadOf` rewrites for a rule that mangles the GitHub URL.

// Cargo itself already swallows this — pattern for callers of github_fast_path:
match github_fast_path(repo, url, reference, gctx) {
    Ok(rev) => { /* use fast-path result */ }
    Err(e) => {
        tracing::debug!("failed to check github {:?}", e);
        // fall through to a normal fetch; never propagate fast-path errors
    }
}

When it happens

Trigger: A git dependency URL that `is_github()` matches as a GitHub host yet has no parseable path segments — e.g. a malformed `github.com` URL, or an edge case produced by URL rewriting/mirroring config. Observed only when running cargo with `CARGO_LOG=cargo::sources::git=debug` or higher.

Common situations: Custom `insteadOf` git URL rewrites, mirror/proxy configurations that transform `https://github.com/...` into something opaque, or hand-edited registry entries. Almost never seen because the result is discarded.

Related errors

• couldn't find username
• couldn't find repository name
• too many segments on URL
• invalid package name: `{url}` Use `cargo install --git {
• `{feature}` is unsupported when inferring the crate name, us

AI-assisted analysis of rust-lang/cargo@0e07a15537 (2026-08-06). Data as JSON: /data/errors/d92b5079268b6e0d.json. Report an issue: GitHub.