-
Suggestion
-
Resolution: Unresolved
-
None
-
None
-
16
-
msysgit has added support for long (>260 char) file paths in Windows, provided all clients and servers explicitly enable the core.longpaths option. They document: "Only enable this if you know what you're doing and are prepared to live with a few quirks." See https://github.com/msysgit/git/commit/c5f98452e98dca292c615000df7973ead63cf29b.
Stash doesn't support long file paths in Git repositories on Windows and has known issues if they are used, see https://confluence.atlassian.com/display/STASHKB/Stash+always+shows+incorrect+Merge+Conflict+in+PRs for example.
This suggestion is to improve Stash so that long file paths can be fully supported on Windows, provided the core.longpaths git option is enabled on the server and all clients.
- is duplicated by
-
- Closed
[BSERV-7665] Add support for long (>260 char) file paths in Windows
This worked for me (https://stackoverflow.com/questions/22575662/filename-too-long-in-git-for-windows):
git config --system core.longpaths true
RAHUL ROY
added a comment - How much long this issue will be there before it gets a resolution? Hi, I have this issue now, when I try to add few files with long file names and create Pull request- I get ""bitbucket server could not create the merge diff for this pull request"
I'm now hitting this issue too.
See below hyperlink relating path limits in the Windows API.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
Maximum Path Length Limitation
In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:_some 256-character path string_<NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)
Note File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections.
Just hit this, luckily pretty easy for us to work around in this case.
I'm running into this issue as well. I'd like to just set core.longpaths to true on the server (it's standard practice for developers to do this on their machines), but this makes it sound like there's another underlying issue in Stash/Bitbucket that makes this a bad solution. I tested it out though and it seems to work - can you elaborate on why setting core.longpaths to true is insufficient?
This is a real issue, if you happen to work for a company where linux is not yet something that can be installed on servers. Solving this by using git's own option to run with long file names seems like an elegant solution for users that cannot switch to linux easily.
Yeah that can hurt a lot,
I tried LongPath Tool Program which helped a lot.