How core.longpaths works in Git

git-core-longpaths.md

I've recently looked into how core.longpaths Git options works and how it's related to Enable Win32 long paths Windows option. Turns out they are not related, and longpaths is both clever and hacky.

Many Windows wide char APIs support longer than MAX_PATH paths through the file namespace prefix (\\?\ or \\?\UNC\) followed by an absolute path. When long paths support is enabled via 'core.longpaths' option, handle_long_path function expands long paths using the '\?' file namespace prefix. See this commit message for detailed explantion.

There's nothing "hacky" in the solution implemented by Git, instead it's the one (and only) correct one. Enabling long paths for Win32 is a hack to by-pass legacy API-limitations for applications which are too lazy to support long Unicode paths, which exist since "forever" in Windows NT and NTFS.

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\?" prefix. For example, "\?\D:\very long path".

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry