|Netbeans changes line-endings ruining pull requests... Any recommendations?||Martimiz||9/21/12 4:38 AM|
Recently I switched to using a Mac and switched to Netbeans from my old Windows editor, but unfortunately it ruins my pull requests, because it changes the line-endings for some lines that I didn't edit. This mostly seems to affect those lines starting with /**
I've searched the web, but can't find a way for Netbeans to leave my line-endings alone. I read it checks the first line ending in the file, and then converts every other line ending to that format. Probably some files in SilverStripe have mixed line endings?
Are there any Mac users around who'd know if and how this can be fixed? If not, can you please recommend another good PHP editor that won't do this, short of editing everything in vi?
|Re: [silverstripe-dev] Netbeans changes line-endings ruining pull requests... Any recommendations?||banal||9/21/12 5:05 AM|
AFAIK the old Mac OS used CR as line-ending which sadly is incompatible
with most version control systems. I had to experience this myself when
I tried to put some ActionScript files in a GIT repository (they have
been edited using the Flash Professional IDE which saves with CR
line-endings on mac).
Apparently Netbeans also uses CR line-endings on mac, which is probably
causing these issues.
I'd switch editor... personally I can recommend the following:
Eclipse (get PHP plugin) :
Coda2 : http://www.panic.com/coda/
Textmate : http://macromates.com/
Eclipse is probably closest to what you had with Netbeans. There's also
aptana (http://aptana.com/) which is an eclipse based IDE for
Cheers - Roman
> You received this message because you are subscribed to the Google
> Groups "SilverStripe Core Development" group.
> To view this discussion on the web visit
> To post to this group, send email to silverst...@googlegroups.com.
> To unsubscribe from this group, send email to
> For more options, visit this group at
|Re: [silverstripe-dev] Netbeans changes line-endings ruining pull requests... Any recommendations?||anselmdk||9/21/12 5:45 AM|
I've been using Netbeans as my IDE on both Mac and Ubuntu for quite a while and have never had trouble with its standard settings and pull requests.
So Netbeans shouldn't be the problem. Maybe it's a problem with some files you've previously opened on Windows?
|Re: [silverstripe-dev] Netbeans changes line-endings ruining pull requests... Any recommendations?||Martimiz||9/21/12 8:06 AM|
Of course it's always only after I post the question, that I find the answer. I had been looking in the wrong direction for weeks. I was focused on line endings, because on sending in a pull request, I was kindly requested to stop my editor from changing line endings. Just now I found out ( by enabling the display of line endings in vi) that it wasn't about line endings at all, but about Netbeans removing trailing spaces instead, which is easy to disable in the editor preferences...
Thanks Roman, Anselm, for you suggestions. Much appreciated :-)
|Re: [silverstripe-dev] Netbeans changes line-endings ruining pull requests... Any recommendations?||Sam Minnée||9/21/12 3:37 PM|
It begs the question:
- should we clean up the trailing spaces on all non-thirdparty code as a single commit? (And perhaps make a phing task to perform this)
- should we enforce this as part of the build test (perhaps with Stig's PHP CodeSniffer) so that they don't get reintroduced?
This seems to be a common trip-up for contributors, because some editors that have that setting enabled by default. Fit also flags trailing white space as a code smell.
A pervasive commit like that will risk conflicts in merge, although that can be dealt with with the "ignore whitespace" settings on the relevant git commands.
We may want to do something similar for tabs vs spaces: currently we have a mix in the codebase, which is kind of embarrassing.
For both of these matters I'd trust only robots (and maybe Germans, Ingo ;-) ) to follow the rules consistently; as such, automated tools seem like the best way forward.
As for an automated test for tabs, my first stab would be that all lines must match:
You sometimes want to add one or two spaces at the start of a line, for example to line up the *s in a docblock. I can't think of a use for 2 but it also seems unlikely that it would be a case where spaces are used as fake tabs.