(9:06:13 PM) The topic for #git is: Welcome to #git, we like graphs | Current stable version: 2.41.0 | First visit? https://gitirc.eu | This channel is logged: https://gitirc.eu/log
(9:06:13 PM) Topic for #git set by gitinfo at 8:44:47 AM on 6/1/2023
(9:32:16 PM) germ: I'm wondering why I have to call `dos2unix' on a patch created on Windows, on files from Visual Studio, and what would be the correct way to `fix' this. (If I don't I get `Hunk #1 FAILED at 73 (different line endings).') Having to call `unix2dos' would have actually made more sense, methink.
(9:35:00 PM) tirnanog: one is converting to unix-style "\n" line endings in this instance. unix 2 dos would be entirely backwards.
(9:36:47 PM) tirnanog: I don't use VS but I hear that it supports .editorconfig files nowadays, which can express a preference for unix style line endings for newly created/saved files. maybe that would help.
(9:39:33 PM) germ: I don't think VS has sthing to do w/ this. I could have wrote them in Notepad I think it'd have been the same, My expectation would be to have to use neither :p. I looked quick on Internet and found one issue reported relating, but it was mark closed and from 2017. I didn't look much in detail yet. Specially now that I know the work around
(9:40:29 PM) germ: I'm a teacher though, and I had to tell it to my students, arfter the fact. Feel pretty stupid :]
(9:42:05 PM) tirnanog: why not? CR/LF is the traditional line-ending format for MS-DOS and Windows. although, notepad learned how to handle LF line endings in one of the windows 10 releases. CR/LF is a total pain from an interoperability perspective.
(9:43:48 PM) tirnanog: git, itself, has a core setting to munge line endings. in my view, it's easier just to use LF line-endings from the outset, wherever possible.
(9:46:06 PM) germ: My 1st intuition was that mingw or whichever run that terminal should be *entirely* CRCF :) but again that doesn't seem to have been what the problen was.
(9:46:35 PM) tirnanog: bring CR/LF into the world of *nix and expect all manner of problems.
(9:52:09 PM) tirnanog: as such, the purpose of dos2unix is to get rid of the carriage returns and to ensure that the resulting file is a valid text file, according to the posix definition thereof.
(9:54:13 PM) tirnanog: (though there are a few implementations and the thoroughness of the process may vary)
(9:58:26 PM) tirnanog: anyway, you get the point. create projects composed of files using CR/LF and expect trouble in the course of interacting with the rest of the world. my advice is just not to do it. even using notepad.exe isn't an excuse at this point (unless one is a windows 7 holdout or such).
(9:59:48 PM) tirnanog: git can handle some cases with its core.autocrlf setting but that's just git.
(10:21:52 PM) germ: right then here how did I get CRLF in the 1st place ? All I must have done is git diff .. > patchfile.
(10:23:03 PM) grawity: from `git diff` *outputting* CRLF, I would guess
(10:23:19 PM) grawity: console stdio on Windows is a bit weird
(10:23:57 PM) gsi_: do the input files that you feed to git-diff have CRLF in them? that's usually how it happens
(10:24:15 PM) grawity: e.g. the file handles actually have a text/binary mode, and default to text so that the runtime automatically outputs CRLF whenever the program writes a LF
(10:24:31 PM) gsi_: and while more recent editors may be able to _continue_ using LF only when you open a file, creating a new file still may suffer from defaulting to CR/LF because Windows
(10:25:40 PM) gsi_: would suggest to inspect the files (the sources, and the diff) in tools that present control chars to you, editors like to hide this stuff from you
(10:26:22 PM) gsi_: maybe there are tiny indicators somewhere in the bottom right hand side corner, but these are easy to miss
(10:30:07 PM) germ: gsi_: Yes I would expect VS source code files on Windows to have Windows line-ending.
(10:31:05 PM) gsi_: explicitly state that "by default" for awareness :) because in general "it depends" (will be configurable)
(10:31:08 PM) germ: and the file patched is also CRLF.. So it's patch.exe on Windows that would need a.. patch ? ;p
(10:31:15 PM) gsi_: just happens that most users stick with defaults
(10:31:52 PM) gsi_: what do you expect the patch utility to do? the CR/LF is in the input, and you want to compare these input files
(10:32:15 PM) gsi_: _not_ reflecting on that input data would be ... unexpected, incorrect, incomplete
(10:32:27 PM) germ: silentlty apply a CR/LF diff on CR/LF files
(10:32:46 PM) gsi_: maybe there are diff options to ignore whitespace (most probably named -w or -b or both), and certainly patch and its like have options to adjust
(10:33:09 PM) gsi_: but then you ignore data which is part of the patch utility's input, which should not be the default, but must be done consciously
(10:34:03 PM) gsi_: do you suggest generating LF only output for consistent CR/LF input? that'd be even more unexpected
(10:34:07 PM) germ: Well the biggest element here is that I'm under Windows
(10:34:20 PM) gsi_: yes and that is your choice :-P
(10:34:33 PM) gsi_: there's no problem with that, you just need to be aware
(10:44:13 PM) germ: (Actually it's not exactly a choice :p) It would be nice if `git diff > file ; patch < file' worked out of the box. I'm trying to break down where it.. breaks down :).
(10:45:59 PM) gsi_: consider the above recommendation to create your files in the LF only convention even if you are on Windows
(10:48:53 PM) gsi_: and/or consider using git apply, and see the patch(1) manpage for the eol related options if you have to interact with whacky platforms' output
(10:48:53 PM) gsi_: or remember to use the conversion tool that you applied, which addresses the very differences between platforms
(10:49:37 PM) redbool__ is now known as redbool
(10:55:51 PM) germ: Thank you, gsi_:,though what would be the different platform here: MinGW ?
(10:57:03 PM) gsi_: what's the meaning of that name?
(10:57:22 PM) gsi_: minimal GNU on Windows? sounds like "subsystem" or "part of a different world"
(10:57:58 PM) gsi_: these tools may reside on the same disk, may interact, but are not a native part of the Windows system (in my book and experience, others may disagree)
(10:58:15 PM) gsi_: the same applies to cygwin with so is not windows
(10:58:29 PM) gsi_: the same will apply to WSL
(10:58:52 PM) gsi_: always the same: remain aware of what you do (you should be, being a teacher)
(11:24:21 PM) The account has disconnected and you are no longer in this chat. You will automatically rejoin the chat when the account reconnects.