gitoxide Files

Bug Fixes

• local clones succeed even if git-upload-pack is not in PATH Local clones spawn the service program, like git-upload-pack, by name and would fail if it could not be found in PATH. This is common on Windows, where git can be installed such that git itself is available but its subcommands are not, for instance with scoop.

Now, when spawning the service program for a local repository fails because it cannot be found, find the same program in the directory that git --exec-path reports - the location git itself uses to run its subcommands - and run it from there. If it cannot be found there either, run the git binary that is always findable with the service as its subcommand, which it can always dispatch.

Remote transports are unaffected - they keep the standard invocation so servers can provide their own implementations - and no shell is involved in any of this.

The newly added gix_path::env::core_dir_program() provides the lookup and may serve other Git-provided programs in the future.

Git for Windows builds with SKIP_DASHED_BUILT_INS and thus does not provide programs for builtin subcommands like git-upload-pack in its core directory. The test now grounds itself in a listing of that directory instead, and the documentation of core_dir_program() points out the difference - such programs are still run through git itself thanks to the second fallback.

Commit Statistics

• 7 commits contributed to the release.
• 50 days passed between releases.
• 1 commit was understood as conventional.
• 1 unique issue was worked on: [#2313]

Commit Details

<csr-read-only-do-not-edit/>