Time Nick Message 01:34 MTDiscord Could someone please explain why Irrlicht uses CR/LF endings instead of LF? 01:35 MTDiscord I'm using vi and the files are chock full of "^M", it's slightly annoying but also afaik unusual. 08:19 sfan5 it was probably initially developed on Windows 08:20 celeron55_ at least vim does support those without showing them, but only if the entire file consistently uses them 08:21 celeron55_ if a single line doesn't have it, then you'll get ^M on all the other lines 08:21 celeron55_ of course depending on configuration 12:21 rubenwardy Brand new system, latest minetest, CMake isn't finding Irrlicht in lib/irrlicht 12:22 sfan5 lib/irrlichtmt 12:22 rubenwardy oh dumb 12:22 rubenwardy the repo is called irrlicht 12:22 sfan5 yeah a bit unfortunate 13:30 pgimeno many repositories require newline normalization; the newlines should be LFs in the repo and are automatically converted on checkout 13:31 pgimeno `git ls-files --eol` shows how git handles EOL for each file 13:37 pgimeno and, why not rename the repo? github can leave a redirection when a repo is renamed 13:39 MTDiscord Would it be a good idea to convert all the line endings to LF? It will be a massive diff lol. 13:42 pgimeno the only problem is the pending PRs, it will cause conflicts on all of them 13:44 MTDiscord Could we try to get all the PRs merged and then change them? There are only a few PRs and none of them should be incredibly difficult to finish afaik. 13:47 pgimeno the X11 selections PR works for me 13:49 pgimeno the other two aren't affected 13:49 sfan5 advantages: it looks(?) better in somer(?) editors or something; downsides: numerous 13:50 sfan5 clear no from me 13:54 MTDiscord Should I use CR/LF line endings in my commits? 13:54 sfan5 you weren't doing that? 13:55 pgimeno it's editor-specific; nano for example always saves without CRs, so a file edited with nano will change all lines. Or if line ending autodetection is disabled when editing with nano, the file can end up having a mix of LF-terminated and CRLF-terminated lines, which may confuse some editors and end up being worse. 13:55 MTDiscord No, I develop on a Linux machine, and I normally assume LF line endings. I guess I should make a habit of always checking on any project I contribute to. 13:55 sfan5 "I normally assume LF line endings" do you type them by hand? 13:56 sfan5 most editors automatically match the standard of the files you're editing 13:57 MTDiscord Oh, maybe the endings were correct then. Vi definitely did not assume the line endings and all the patches I implemented have LF endings, which is why I'm asking before PRing. 13:57 sfan5 if you only edited cmake files so far that may indeed be correct, those are LF-only 13:59 MTDiscord Ah. Well the OpenBSD patches I implemented only modified source code... ? 14:01 MTDiscord How on earth do I set Vi to use CR/LF line endings. Maybe it's unsupported. 14:04 sfan5 http://vimdoc.sourceforge.net/htmldoc/options.html#'ffs' it does automatic detection 15:54 nrz /r 17:57 MTDiscord sfan, I'm not using vim, I'm using vi. 18:10 Krock will merge #11549, #10141 in 10 minutes, followed by manual squash of #11262 18:10 ShadowBot https://github.com/minetest/minetest/issues/11549 -- Optimize vector length calculations by Kalabasa 18:10 ShadowBot https://github.com/minetest/minetest/issues/10141 -- Add group-based tool filtering for node drops by Treer 18:11 ShadowBot https://github.com/minetest/minetest/issues/11262 -- [NO SQUASH] Joystick sensitivity for player movement by NeroBurner 18:13 Krock however, it does look like commit 1 already covers all areas 18:14 Krock hence squashing wouldn't make a big difference 18:15 Krock opinions... sfan5 ? 18:21 sfan5 i think squashing 11262 is fine 18:21 Krock I think so too. thanks. 18:21 sfan5 @josiah_wi oh, better test out what it does then if you want to know 18:22 Krock merging 18:22 MTDiscord Vi isn't automatic and has no option. I have installed vim to do the conversion, and it's PRd. 18:24 Krock done