Yet somehow, when I edit a file that has ‘unix’ line endings locally (lf), push them to the subgit repos and it tries to forward them, I’m seeing CRLF at the svn server?
Hi Oliver,
a question has come to my mind right away, sorry if that is too silly, but just in case – I’m recalling I’ve seen editors in Windows that changes eols silently when edit a file, could it be the case here that the editor used in Windows implicitly changes EOLs and Git client is configured to send the files to the repository as they are?
If not, could you please also check out if core.eol is set in Git config and there are any specific settings for those files in .gitattributes – this can also be the cause, if, for example, core.eol is set crlf. Also, it may worth checking the svn:eol-style and svn:mime-type properties in SVN, too – SubGit’s translate.eols set to false only disables translating .gitattributes to SVN properties, but the properties can be set directly in SVN.
Not subgit’s fault, nor gits, nor svns. The ssh daemon on the server was not openssh and was doing end-of-line translations to the tunnel being used.
And it’s not even a monday.
Hi Oliver,
glad you managed find out the cause! I’ve never heard about ssh that would change line endings… it must have been pretty hard to catch this, thanks for sharing!