[postgis-devel] extras/tiger_geocoder/upgrade_geocoder.bat and CRLF

Regina Obe lr at pcorp.us
Tue Aug 8 09:42:49 PDT 2017


> I've installed subversion to try at understanding this issue.
> On the SVN side, checking out the file results in a file with CRLF.
> On the GIT side, checking out the file results in a file with only LF, which is automatically injected CR after download, becoming the same as the SVN checkout.

> The difference is that on the SVN side you see no difference (`svn diff` shows no diffs) while on the GIT side you do see the difference.

> My suspect is that SVN is just ignoring the line ending, intentionally hiding what's on the server side and always showing CRLF on the client side. 
> Maybe if the file was marked as a binary file rather than text file things would be different.
That's my recollection that SVN always maintains the line endings on server based on server's OS lb requirements

> I don't see how could an SVN only user possibly see what's being committed at this point :(

According to
http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html
the `svn:eol-style` setting value 'CRLF' (what is in current use for `extras/tiger_geocoder/upgrade_geocoder.bat`) should ensure server side has `CRLF`.

> At this point I'm guessing it is the GIT side messing things up, some wrong configuration in .gitattribute ?

> --strk;

Yes it does seem that git is the culprit here or the mirror.  But .gitattributes works as expected on other files and checking winnie's latest pull (which is using git) I can confirm she see's CRLF in the upgrade_geocode.bat and LF in the files we designated, so .gitattributes is doing it's job. 

Are you sure you don't have another git setting overwriting things or something in the mirror overwriting?

Recall the reason we added .gitattributes is because otherwise we can't compile on windows under (at least not under mingw) without it.

In particular what used to happen before we had it is

When doing a git clone or git pull from, it would not maintain the line endings committed
So all the files would get pulled down with CRLF line breaks instead of LF linebreaks.  

This is normally okay except under mingw compile (not sure how VCC would behave) in particular with files .ac, .h.in, .h. GNUMakefile.in (most of  the files we have rules for in .gitattributes)
If it saw a CRLF in them in would choke and give strange error messages.

Now my question is if your git is obeying the .gitattributes, it should not be pulling down the files .bat with anything but CRLF.

Maybe there is a setting in svn and git where we can say preserve linebreak (that might be same as marking them binary I guess)






More information about the postgis-devel mailing list