You run into the Windows path limitation.
GE executes Git in WSL using wsl.exe, using the current Windows path. This is also why the UNC prefix is added.
This is a Windows limitation (possible to get around in some way). A custom server in WSL could also work. This is not something that is planned (a big undertaking.)

@gerhardol Thank you for the response.

Yes, we stumbled upon the path limitation in Windows with git and hoped to circumvent it using wsl.

There seems to be a support within GE, since the clone process in general is working (without the UNC prefix). The data is available and can be seen even with the windows file explorer. The strange thing is, that the added prefix by GE leads to an error (see 1.).

Since just the opening of the repo afterwards with GE is not possible, I think it is not a wsl.exe or Windows issue. Does GE use a newer Windows API with LongPath support?

Maybe I am also using GE wrong for the LongPath? I searched within the docu, but did not find anything for long path usage.

Again, thank you very much for your time and support

You can clone, then the path is just a parameter. When opening, the working directory is set that wsl.exe or GE does not like.
GE is to my knowledge not explicitly built with long paths, but wsl.exe must work too.

wsl.exe may use long paths but it requires a registry patch:
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=powershell

PS Microsoft.PowerShell.Core\FileSystem::\wsl$\ubuntu-20.04\home\user\gc\loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong\tmp_tests> dir

Directory: \\wsl$\ubuntu-20.04\home\user\gc\loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooong\tmp_tests

Mode LastWriteTime Length Name

d----- 2024-10-07 22:47 .git
------ 2024-10-06 15:58 1071 LICENSE

PS

However git.exe (that is used occasionally also in wsl) have limitations:
PS Microsoft.PowerShell.Core\FileSystem::\wsl$\ubuntu-20.04\home\user\gc\loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong\tmp_tests> git status
Program 'git.exe' failed to run: The directory name is invalidAt line:1 char:1

• git status

At line:1 char:1

• git status

•     CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
      FullyQualifiedErrorId : NativeCommandFailed
  
  

PS

WSL Git is OK:
~/gc/loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong/tmp_tests$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

It is no point in enabling long paths in GE right now

About the registry:
Yes, I knew about the registry and have set it...but the manifest needs to be provided as well for the application to activate long path support. So there are two steps for activating long path (and it seems that the second step is mostly overseen by users and developers).

About git.exe or wsl git:
Why is the git.exe sometimes used when working with wsl?
What I have found out for GE is: If the last opened repo is located in Windows, the git.exe is used...even for cloning into a new wsl folder. If you switch to a wsl located repo wsl git is used.

The issue really seems to be that it is not possible to launch any executable (even notepad.exe) if you are in a folder with more than 256 chars.
I don't know the full call stack for running wsl git. But the issue seems to be the console in which the call is executed? Is there maybe another long path aware console available?

One of the reasons most developers put their repos in a folder like c:\git or such. Doing the same but a similar wsl path may mitigate.

Yes, this is true. Of course the provided example is synthetic. Nevertheless, we are using nested submodules with multiple layers and thus run into this issue.
BTW: If you clone git itself (with one submodule) sowhere near the edge of the 256 chars (again a synthetic example), it is not possible to switch into the submodule with GE.

I have also created an issue @ git for windows. Unfortunately, the developers do not see a solution for the bash-based submodule feature ( git-for-windows/git#3372 and a partial solution git-for-windows/git#3877 ).

Thus, the idea for the workaround to work with GE and wsl.

The only explicit WinGit use I see is for custom diff and mergetools, using _gitWindowsCommandRunner/_gitWindowsExecutable.
There are some situations Git commands are called without requiring to be in a repo, in settings and probably when cloning too.
WSL is a hack as it is already. Maybe no hacks for Git handling is required, if usage is "careful".

But changes are needed in the application too, some APIs need to be changed. I did not see what should be done to the stacktrace for this example (the manifest may have been incorrect though.)
For this to be changed, someone really interested need to work on this,