Thanks for confirming!

This is no SmartGit, but rather a Git issue.

You mean the warning produced by Git? That won't be possible and even if, it wouldn't be a good idea. I'd rather recommend to adjust your core.autocrlf/.gitattributes:

https://stackoverflow.com/questions/5834014

> 1) As we maintain multiple repos, I'd have to either use a more flexible .bat or change .bat with fixed paths for each repo? 

Yes, I guess the batch file must somehow manage that. SmartGit will execute the batch file with the correct Windows working directory set; but the mapping to WSL it doesn't know. For a given setup it shouldn't be too hard with some String acrobatics. Regarding a more general solution, there might be a way to figure out the full UNC patch for e.g. S:\home\marc\github.priv3 [1].

> 2) Even though pulling/pushing/fetching/ls-remote {url} within WSL works fine, when started from smartgit it returns "Could not update branch states (green and red arrows) due to: ls-remote failed (return code 1)". Credential helper is set to cache.

We can tweak SmartGit to pass any credential.helper to the Git executable which you like, but ultimately it's the Git executable in WSL which must be capable of establishing the connection.

You can see all commands which SmartGit is invoking in the Output view. What are your concrete suggestions on how these commands should be altered?

[1] https://stackoverflow.com/questions/21482825/find-unc-path-of-a-network-drive

My repository is located at ~/github.priv3 and I'm using following git.bat file (hacked together, for testing):

wsl cd ~/github.priv3 ; git %*

To avoid the "UNC paths are not supported" error, I've mapped network drive S:\ to the root of my WSL file system and I'm opening the repository from S:\home\marc\github.priv3

In the VM, I have configured once:

git config --global credential.helper cache

and after every WSL 'boot' I ensure that Git will have cashed credentials by invoking from within WSL a

git pull

Note that:

git config --global credential.helper store

will even survive WSL reboots (but will write credentials in plain text into your WSL file system).

This basically works. SmartGit shows "git: 'credential-D:/smartgit/build/dist-templates/windows/lib/credentials.cmd' is not a git command. See 'git --help'.", but this can be ignored for now.

Hence, IMHO, we have all ingredients present and working, just the approach needs to be refined and we probably needs some SmartGit option to omit the "credential.helper".

> I've tried both wslgit workarounds and consider them kind of hacky, running into credential helper issues all the time.

Did you also try the workaround suggested in my previous post?

• Git executable inside WSL should be used
  => a simple batch file basically works:
  wsl git %*
• requesting credentials does not work
  => The Git credential helper must be configured to e.g. "credential.helper=cache" and credentials must be configured in a way that Git won't have to ask for credentials (avoid command line prompt!)

Sorry, I can't give an ETA at this unclear stage.

Basic partial clone support is present now. For details, have a look at my today's comment at:

https://smartgit.userecho.com/en/communities/1/topics/1223-

This has been implemented now for 21.1 Preview:

https://www.syntevo.com/smartgit/preview/

build 17044+ (use Help|Check for Latest Build, if necessary). Changes:

• All relevant code should fetch blobs on demand, if not, please report as bug
• For treeless clones (tree:0), relevant code should show a reasonable warning message that processing is not possible; for reasons, see https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/
• The Clone wizard will offer to skip files larger than a certain size (0 is allowed and means "blob:none")
  

We hope to have identified all code parts which fetch a large amount of blobs (like File Log, Blame, Investigate) and properly changed this code to do a few large fetches, so overall execution time should be reasonable. If you encounter long-running operations for which blobs are still fetched one-by-one (you will see this in SmartGit's log.txt.0 file), please report back.

Given this topic has been posted 3 years ago and there is now WSL2, which issues are still present? According to my understanding there are following possible combinations:

• WSL1: access repository located on Windows file system
  => why would one use WSL's Git here instead of a Windows Git?
• WSL1: access repository located on Linux system
  => is this possible at all with WSL1? If so, probably issues are similar to WSL2 (see below)
• WSL2: access repository located on Windows file system
  => why would one use WSL's Git here instead of a Windows Git?
• WSL2: access repository located on Linux system
  => most interesting case, but works only quite limited using \\wsl$\-paths

Configuration-specific problems:

• line-ending related issues
  => "core.autocrlf=false" should be set for the repository
• executable bits are not detected, but still compared
  => a workaround is to set "core.filemode=false" for the repository
• Git executable inside WSL should be used
  => a simple batch file basically works:
  wsl git %*
• requesting credentials does not work
  => The Git credential helper must be configured to e.g. "credential.helper=cache" and credentials must be configured in a way that Git won't have to ask for credentials (avoid command line prompt!)

SmartGit-specific problems when accessing \\wsl$\-paths:

• slow refreshing due to timestamp precision issues
  => not too hard to fix in SmartGit code
• symlinks can't be read (tested with Java 13):
  Caused by: java.nio.file.FileSystemException: \\wsl$\Ubuntu-20.04\home\marc\symlinks\links\link: Incorrect function.
at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
at java.base/sun.nio.fs.WindowsFileAttributeViews$Basic.readAttributes(WindowsFileAttributeViews.java:53)
at java.base/sun.nio.fs.WindowsFileAttributeViews$Basic.readAttributes(WindowsFileAttributeViews.java:38)
at java.base/sun.nio.fs.WindowsFileSystemProvider.readAttributes(WindowsFileSystemProvider.java:198)
at java.base/java.nio.file.Files.readAttributes(Files.java:1842)

Which WSLGit are you using?

- https://github.com/andy-5/wslgit
- https://github.com/hangxingliu/wslgit
- some other?