BuildSys - autocrlf
Herbert zur Nedden (9470) 41 posts |
Hi, may I pass on a few suggestions for the BuildSys – basically due to oddities I was experiencing: When you use git on windows it will by default amend the line endings from LF to CRLF. Sounds harmless, bis a pain since Perl and DDE cc can’t cope with that in some cases:
So my suggestion is to prominently include in the guide the command “git config —global core.autocrlf false” for Windows users. In addition perhaps the Build app can read some text file that was fetched from git (be it some source code file or perl script) and check that the line endings are just LF and if they are not to tell the user that the aforementioned git config command should be run before using git. |
Stuart Swales (8827) 1357 posts |
Might have been 1989 when I reported that…
Wouldn’t |
Herbert zur Nedden (9470) 41 posts |
if you use a decent text editor in Windows like Notepad++ it does not change the line endings or the encoding unless you ask it to do so explicitly. |
Steve Pampling (1551) 8170 posts |
Setting it to be the default text editor of the OS is icing on the cake. |
Charles Ferguson (8243) 427 posts |
Requiring a configuration like that on individual repositories is the wrong way to approach such problems – it means that you require users to configure things correctly and if they don’t you introduce broken content. If you want a specific file (or class of files) to have a specific line ending format, the correct way to do so is to configure the specific file (or class of files) in the .gitattributes file so that the files are always formed properly, regardless of the user’s configuration. *,102 text=lf *.pl text=lf |
Herbert zur Nedden (9470) 41 posts |
Nice idea Charles – but not quite what I’d suggest, I dare say! Normally if I use a Windows based environment git changing the line endings to the default of the OS I use is even a good idea (though with a decent text editor the line endings can be LF or CRLF on Windows); if I’d use a Linux based setup same applies. But we do things weird since there is no git client that I am aware of for the platform to use (RISC OS) so we have to run git in some alien system and then copy the files over – and thus need to be aware of such oddities and figure out how to address them – rather on some global level since there are lots of text files (or files git might consider to be text), be it Perl scripts, C or Assembler sources, obey files, or whatever… to adding rules for them all to the .gitattributes might be a bit demaning or even miss out the odd one. Basically nowadays I’d even expect that some tool using text files should get along with different line endings since LF as well as CRLF are very common and cross platform file transfer is pretty common – but since at the time being we do not have that so asking git to not adjust the line endings to Windows format is probably the easiest way to got – apart from using it inside WSL or with native Linux. |
Ian Clark (1610) 2 posts |
According to the documentation a .gitattributes file of the form:
will suffice. Asking a user to change a global attribute could have knock on effects on other repositories they’re using. If It’s something that is required for the repository, it should be specified in the repository. |
Charles Ferguson (8243) 427 posts |
That will disable all end of line processing, which will mean that when you edit files on Windows you run the risk of adding in CRLF sequences which will then break other platforms. Of course, most modern editors will be just fine with adding only the endings that are appropriate to the file you’re editing, so maybe that is unlikely. In any case, I wouldn’t apply such a thing to |