Zig fetch error - could not be recognized as a file path

SpinTensor · November 27, 2025, 6:45am

Hi,

I want to fetch a repo from a gitlab server
cloning it with git works fine

git clone git@gitlab.the_server_of_my_choice.de:my_id/my_project.git

But if I want to fetch it with zig fetch I get

zig fetch --save git+ssh://git@gitlab.the_server_of_my_choice.de:my_id/my_project.git
error: 'git+ssh://git@git@gitlab.the_server_of_my_choice.de:my_id/my_project.git' could not be recognized as a file path (FileNotFound) or an URL (InvalidPort)

Sorry that I cannot give access to the fetched repo for testing purposes, but it is marked institution internal.

castholm · November 27, 2025, 7:36am

zig fetch only supports the git+https scheme, e.g. zig fetch --save git+https://gitlab.com/foo/bar.git. The Git server must also support this protocol (which I believe GitLab does, but I’m unsure if it’s also the case for self-hosted).

tsdtas · November 27, 2025, 8:07am

I also have this problem (internal resource, only SSH access).
Here’s the issue tracking ssh fetching:

github.com/ziglang/zig

ability to fetch dependencies via git+ssh protocol

opened 05:12AM - 13 Jan 23 UTC

andrewrk

enhancement contributor friendly zig build system

Extracted from #14265. `zig build` should support fetching via an URL like th…is: ```zig .url = "git+ssh://git@github.com:ziglang/zig.git#8b8090d7fad3e444784bc52db6a80188a9dbd3c0", ``` Note that the fragment is used to fetch a particular commit. I suppose the fragment could be omitted, meaning to fetch the latest HEAD of the default branch, however, this would be not advised since the hash would be wrong as soon as another commit is pushed to that branch. Ideally, if the fragment is omitted then an error would be emitted telling the user to add the fragment, giving them a copy+pasteable snippet, or perhaps even editing the manifest file on the user's behalf. Open question: should it be built-in? or is this issue a request for a third party contributor to make a fetch plugin (#14294)? I think the first step would be to implement this as a third-party fetch plugin, and then we can evaluate whether it can be upstreamed and become a builtin. Related: * #14296 * #14297 * #14298

For now I think cloning it manually and then adding it with .path = "../foo" instead of fetching it is probably the cleanest option. We tried experimenting with adding a “meta-dependency” that fetches with SSH in a seperate build.zig via addSystemCommand calls to git, but it just felt like more of a hassle to maintain that than having to clone a repository once in a blue moon.