Windows - Error importing/refreshing a deps project (with git deps) when Intellij's git runs on WSL

[bobisageek]

Context

• Windows 10 Enterprise (work machine) w/ an Ubuntu instance running in WSL
• Cursive 1.14.0-2024.3 on IJ 2024.3.1

On Windows, Intellij can be configured to use a git installation that runs in WSL. This is done by setting Settings->Version Control->Git->Path to Git executable to something like \\wsl$\[WSL VM name]\usr\bin\git. This setting can also be set "for the current project".

Issue
If Intellij is configured to use git from WSL, importing or refreshing a deps project that needs git deps appears to cause Cursive to also use the git from WSL, which causes an error:

The following errors were found during project resolve:
C:\path\to\repo\deps.edn:
Cannot run program "\\wsl$\Ubuntu\usr\bin\git": CreateProcess error = 193, %1 is not a valid Win32 application

By "needs git deps", I mean the "effective deps" (based on selected aliases) include one or more git deps. In my use case, I have a git dep (cognitect's test runner) in an alias. If I de-select that alias (so there are no "effective" git deps), refreshing the project works as expected. If I select the alias, the aforementioned error occurs.

From what I can tell (caching seems to make it a little hard to tell), setting the git path to a Windows git executable, either globally or for that project, causes Cursive "project resolve" to use that Windows git (and to resolve git deps as expected), so that serves as a workaround (with the side effect of also using Windows git for the project as a whole).

Desired Behavior

I guess ideally I'd like parity, as in Cursive being able to use any git executable that IntelliJ can use. I have no idea if that's realistic/feasible. Adding a different git executable setting just for Cursive seems to me like overkill for this somewhat esoteric scenario, but I would probably use it if it were present.

This is more a solution than a behavior, but I also don't know if using something resembling clj -X:deps prep and letting that fetch git deps (potentially using its config) would fulfill the requirements to import/refresh the project.

The workaround of setting the git executable for Clojure projects is less than desirable in my use case, but not a crisis.