`uv init` fails to create .git directory or .gitignore file when inside git repo

[mason-fabel]

Summary

When inside of a git repo, running uv init my-project --vsc=git does not create a .git directory or .gitignore file in my-project.

For example, my $HOME is a git repo containing my dotfiles, and I'm trying to create an uv project at $HOME/dev/my-project.

Output

$ uv init my-project --vcs=git --verbose
DEBUG uv 0.6.2
DEBUG Checking for Python environment at `my-project/.venv`
DEBUG Searching for default Python interpreter in managed installations or search path
DEBUG Searching for managed installations at `/home/username/.local/share/uv/python`
DEBUG Found `cpython-3.13.0-linux-x86_64-gnu` at `/usr/bin/python` (first executable in the search path)
DEBUG Writing python versions to `/home/username/dev/my-project/.python-version`
$ rm -rf my-project
$ uv init my-project --verbose
DEBUG uv 0.6.2
DEBUG Checking for Python environment at `my-project/.venv`
DEBUG Searching for default Python interpreter in managed installations or search path
DEBUG Searching for managed installations at `/home/username/.local/share/uv/python`
DEBUG Found `cpython-3.13.0-linux-x86_64-gnu` at `/usr/bin/python` (first executable in the search path)
DEBUG Detected existing version control system: git
DEBUG Writing python versions to `/home/username/dev/my-project/.python-version`
Initialized project `my-project` at `/home/username/dev/my-project`

Example

git init
uv init my-project --vcs=git
cd my-project

# Expected: default uv .gitignore file
# Result: cat: .gitignore: No such file or directory
cat .gitignore

# Expected: new .git directory
# Result: ls: cannot access '.git': No such file or directory
ls .git

Platform

Fedora Linux 41 (Sway) - Linux 6.12.4-200.fc41.x86_64 x86_64 GNU/Linux

Version

uv 0.6.2

Python version

Python 3.13.0

[mason-fabel]

Maybe this shouldn't be labelled as a bug? Reading the comments at

uv/crates/uv/src/commands/project/init.rs

Lines 1221 to 1229 in 6d3614e

	(Some(vcs), Some(existing)) => {
	// If they differ, raise an error.
	if vcs != existing {
	anyhow::bail!("The project is already in a version control system (`{existing}`); cannot initialize with `--vcs {vcs}`");
	}
	// Otherwise, ignore the specified VCS, since it's already in use.
	VersionControlSystem::None
	}

it looks like I'm running into an intentional design (or at least an unconsidered edge case).

I get what uv is doing by default, it's probably the correct default even, but I would like something like uv init my-project --vsc=git --force to confirm that I really mean it when I'm asking for a fresh .git directory and I know what I'm doing. I'm borrowing the --force flag from git, I have no particular attachment to that name.

[zanieb]

I feel like this is a valid use-case. I think we could perhaps treat an explicit --vcs=git as "force" (vs the default "auto" behavior)

[mason-fabel]

That makes sense to me. In fact, that's what I initially assumed would happen and led to this issue.

I haven't finished setting up the repo locally, but I'm happy to work on a patch for this. Would (Some(vcs), Some(existing)) => vcs be an appropriate solution, or are there other edge cases I'm not aware of in play here?

[Chaoses-Ib]

Regarding the default behavior, how about creating .gitignore but without .git? Currently, one has to write .gitignore manually if the project is inited inside an existing repo that doesn't have ignore rules for Python. If uv creates .gitignore by default, this can be skipped, and if someone doesn't want it they can simply remove it, much eaiser than the opposite.

[mason-fabel]

@Chaoses-Ib I don't understand, what are you proposing? Are you saying uv init <project> should always create a .gitignore, even when <project> is inside a git repo?

[xuatpham]

@Chaoses-Ib I don't understand, what are you proposing? Are you saying uv init <project> should always create a .gitignore, even when <project> is inside a git repo?

as I see, default, when I do: uv init project-name , uv will auto create .git & .gitignore .
but if I do uv init project-name inside another git repor, it won't.