Summary

When running a script via uv run that depends on a Git dependency, uv’s internal git fetch may misbehave if the environment variable GIT_DIR is set. This can easily happen with git bisect run uv run.

For me, this had the effect of breaking the uv run:

   Updating https://github.com/labgrid-project/labgrid (master)
  × Failed to download and build `labgrid @ git+https://github.com/labgrid-project/labgrid@master`
  ├─▶ Git operation failed
  ├─▶ failed to clone into: /home/afa/.cache/uv/git-v0/db/97a5d45ad0e4ae1c
  ├─▶ failed to fetch commit `c246fab86fe451db46507b77bc7fe58aaad3a79e`
  ╰─▶ process didn't exit successfully: `/usr/lib/git-core/git fetch --force --update-head-ok 'https://github.com/labgrid-project/labgrid'
      '+c246fab86fe451db46507b77bc7fe58aaad3a79e:refs/commit/c246fab86fe451db46507b77bc7fe58aaad3a79e'` (exit status: 128)
      --- stderr
      fatal: not a git repository (or any parent up to mount point /home)
      Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

and mangling the repository I wanted to bisect:

fatal: this operation must be run in a work tree

Because uv turned it into a bare directory, instead of presumably ~/cache/uv/git-v0 instead.
I turned it back to a regular repository with:

git config set core.bare false

But I am not sure yet, what other unintended modifications uv may have done to my git repository.

I reproduced with uv 0.7.13 and git version 2.47.3.

This is similar to #16102 which was closed after a workaround was found.

Due to the potential for data loss, I think uv should explicitly unset GIT_DIR and possibly other variables that can influence what repo uv's internal git invocations operate on.

Platform

Linux 6.19.6+deb13-amd64 x86_64 GNU/Linux

Version

uv 0.7.13

Python version

Python 3.13.5