Make uv init resilient against broken git

[konstin]

Currently, uv init works without a git executable, and with a working git executable, but not with a broken git, be it from GitHub Action's Windows CI or from the shim we insert.

uv init calls git twice: Once git rev-parse to check whether a git repo already exists, and then git init (if there is no git repository yet and no --vcs none).

By separately handling the cases where git failed during git rev-parse doesn't work vs. where the is no repository when checking for an existing repo work tree, we can avoid calling git init for broken git and erroring. We have to hardcode the expected git command outputs to be able to check.

[zanieb]

Suggested change

	"`git rev-parse --is-inside-work-tree` failed to launch for `{}`",
	"`git rev-parse --is-inside-work-tree` failed for `{}`",

[zanieb]

Actually, I might prefer it as-is 🤔 do what you prefer!

[konstin]

I like the current versions for pointing out that this isn't case of a non-successful exist status, but one where git failed to spawn as a subprocess.

[konstin]

The main questions here are: a) Are we ok with parsing git text output? b) Do we want to ignore broken git installation? c) Does that interact properly with the git test feature?

[zanieb]

What's the behavior if without --vcs?

[konstin]

That's tested above with context.init().arg("working").assert().success();

[Gankra]

GitHub Action's Windows CI

...what on earth is happening here??

[Gankra]

I'm definitely suspicious of this but I doubt these outputs change much and other tools are liable to freakout if they do.

And this is pretty narrowly scoped so if it's an issue it's unlikely to cause massive breakage for people.

[konstin]

Since we seem to be aligned on doing this I've polished the PR into a mergeable state