Long file names fail under Windows

[Freymaurer]

Hey! So for now we added the git terminal view to remove silent fails!

The issue with long file names still persists but is visible!

At the moment, we are undecided on how to approach this. Should we apply settings to git for the user or should we just return a sensible error?

I will close this issue and open a new issue, in which this can be discussed!

Originally posted by @Freymaurer in #183

[Freymaurer]

@eik-dahms @micwij

[eik-dahms]

I would suggest to do this on start up.
Check if windows -> check global config core.longpaths is set to true if not do ->

git config --global core.longpaths true

this should set the config globally for the current user. This should not require additional permissions and will be read by any git command executed by the current user.

this should be working without changing the windows settings, but should be tested anyways.

Alternatively:

• this could be done in each repository separately. But this would be more complex and error prone.

• there could also be a length limit on filenames, but that is rather impractical. especially if the filenames are generated external entities where you can not influence how things are named.

[kMutagene]

Maybe related? https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#maximum-path-length-limitation

[eik-dahms]

@kMutagene the mentioned "\?" prefix is what git uses if you turn set the core.longpaths to true.

git/git@0f634d0

[Brilator]

Just a reminder, that people (esp. on windows) keep running into this issue and the ARCitect cannot handle it.
git config --global core.longpaths true. This worked for me.

[JonasLukasczyk]

this flag has been added since 0.0.51