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?

What is the "root directory name"?

OK. I have updated the title and description.

I would limit the marker check in code only to those lines which you have modified. So, only if you are modifying a line which already contains such a marker from previous commits, that would result in a false-positive warning.

For myself this check would work better than an explicit action in SmartGit, because I'm already using such TODO-markers anyway (e.g. IntelliJ IDEA has special support for them) and thus there is zero overhead to have such a check working. If I had to switch from IDEA to SmartGit and invoke some additional operation there, that would be cumbersome.

Is this something which could be told from the diff of the file? E.g. because the diff contains markers like "TODO"?