> Hi. >
> I got your address from Michael Geddes via the git mailing list as
> the primary developer behind unicode file name support on Windows.
> ran into a problem with msysgit. I'd like to bring it to your
> attention as part of your effort. >
> I have a repository with Adobe Indesign SDKs in it that are very
> deeply nested. When I tried to clone this repository on Windows, I
> got an error during the initial checkout of 'master' because the
> path names exceeded MAX_PATH (260 bytes). It appears that on
> Windows, the way to bypass the MAX_PATH limitation is to use the
> unicode versions of the I/O functions and prepend "\\?\"
to the pathname. > > example (CreateFile)… http://msdn.microsoft.com/en-
> us/library/windows/desktop/aa363858(v=vs.85).aspx >
> Has your work addressed this issue? If not, how much work would it
> be to add support for extended file paths? >
[Adding cc:msysgit, perhaps someone there is more
knowlegeable than me regarding this issue]
While the Unicode version almost exclusively uses
wide-char APIs, it also limits all filename conversions to MAX_PATH (260)
characters, so no, my work doesn't address the long filename issue.
IMO, to lift the MAX_PATH restriction in Git for Windows
would be quite difficult (that's why I didn't even bother when implementing
the Unicode stuff): 1.) git almost exclusively uses relative paths, and
\\?\ can only be used with absolute paths. 2.) most git core path operations are limited to PATH_MAX
characters anyway (259 on MinGW/Windows).
And then of course there is the issue that on some
Windows versions, Windows Explorer will simply crash with path names >
Perhaps you could restructure your repository so that
it uses shorter paths?