You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I'm currently using TortoiseGit and Git for Windows because I like the integration into Windows Explorer pretty much and has long time worked with TortoiseSVN already. Though, because being a Windows Explorer integration, under some circumstances TortoiseGit suffers from the max path length problem of Windows Explorer being 260 chars.
While Windows itself doesn't have that problem if long Unicode paths are used by an app, Windows Explorer has its own concept of paths and doesn't support this. This e.g. results in that Git for Windows supports a config "core.longpaths = true" and hence is able to e.g. recognize changes in files or revert files which some dialogs of TGIT itself can't handle. It then says something like it knows that a file was modified, because some native Git for Windows tells that, but can't access the file using Windows Explorer API to e.g. show DIFFs and stuff.
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".
So what about SourceTree, does that support long Unicode paths in Windows everywhere? And if so, does it support that by properly building paths as documented above or does one need to enable the newly introduced registry workaround?
Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.
Thanks for your input!