Git Dependencies Fail When Using `init.defaultBranch=main` & `includeIf`
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 15.5k
- Forks
- 3k
- Avg merge
- 23h 30m
- Merged PRs (30d)
- 51
Description
Problem
I'm trying to use a git dependency while I wait for a patch to make its way to an upstream crate. I follow the instructions to specify a repository, only to get the following output:
$ cargo build
Updating git repository `https://github.com/p0lyw0lf/boa.git`
error: failed to get `boa_engine` as a dependency of package `query v0.1.0 (/home/me/github2/driver/query)`
Caused by:
failed to load source for dependency `boa_engine`
Caused by:
Unable to update https://github.com/p0lyw0lf/boa.git?tag=v0.21
Caused by:
the repository is not empty; class=Invalid (3)
I noticed that removing my ~/.gitconfig makes this problem go away, and bisecting the configuration led me to the section [init] defaultBranch = main as the culprit: removing just that or changing it to master resolves this issue.
Steps
Here's a reproduction script, meant to be run inside a container:
#!/bin/bash
set -euo pipefail
# Step 1: set up "interesting" .gitconfig situation
cat <<EOF > ~/.gitconfig
[includeIf "gitdir:/"]
path = ~/other.gitconfig
EOF
cat <<EOF > ~/other.gitconfig
[init]
defaultBranch = main
[user]
email = test@example.com
name = test
EOF
# Step 2: create library crate & copy revision
cd /
rm -rf a
cargo init --lib a
cd a
# 2.1: Check to make sure git knows about init.defaultBranch
git config list
git add .
git commit -m "initial commit"
# 2.2: Cargo doesn't know about init.defaultBranch when provided this way,
# and seems to keep the default name.
rev=$(cat .git/refs/heads/master)
# Step 3: create binary crate & add git dependency
cd /
rm -rf b
cargo init b
cd b
cat <<EOF >> Cargo.toml
[dependencies.a]
version = "0.1.0"
git = "file:///a"
rev = "${rev}"
EOF
# Step 4: run build, see it fail
cd /b
cargo build
and Containerfile that I ran with podman build ., for reference:
FROM rust:latest
WORKDIR /
COPY repro.sh /
RUN chmod +x repro.sh && ./repro.sh
Expected: b pulls in a without issue.
Actual: you should see an error with "the repository is not empty; class=Invalid (3)"
Notes
This might be an upstream git issue: both the git cli and libgit2 backends resulted in the same outcome; I have not yet tried the gitoxide backend however. Looking at the fetch in ~/.cargo/git/db, the HEAD file has the contents
ref: refs/heads/master
And in either case, the ~/.cargo/git/db directory is unchanged whether init.defaultBranch is master or main.
Version
cargo 1.94.0 (85eff7c80 2026-01-15)
release: 1.94.0
commit-hash: 85eff7c80277b57f78b11e28d14154ab12fcf643
commit-date: 2026-01-15
host: x86_64-unknown-linux-gnu
libgit2: 1.9.2 (sys:0.20.3 vendored)
libcurl: 8.17.0-DEV (sys:0.4.84+curl-8.17.0 vendored ssl:OpenSSL/3.5.4)
ssl: OpenSSL 3.5.4 30 Sep 2025
os: Debian 13.0.0 (trixie) [64-bit]
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running the reproduction script and Containerfile, then compare the git dependency fetch through the git CLI and libgit2 backends mentioned in the report. Trace the cargo build path that initializes the repository under ~/.cargo/git/db, including its handling of HEAD and init.defaultBranch. Done means the example pulls in the local crate successfully with the includeIf configuration and the reported error no longer occurs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, rust
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100