Hi Igor, In line with almost all "version control" systems, Git takes the view that what is in the reposititory 'is' the versioned artefact, rather than some small (allowable?) variant of it.
There is some on going work on ensuring that the CRLF line ending choices of a user can be accomodated. However the area of auto adjustment has lots of hidden issues, especially given the *nix freedoms to put anything anywhere (e.g. a loose CR in the middle of a text line). Then there is the historic Mac CR conventions. I've not seen the patch issue, though I only use them to submit patches from a windows PC to the main git list (rather than applying them the other way around). Patches always have CRLF as the eol (that's the email RFC standard, IIUC). Getting your setting right can be a challenge as there are a lot of old 'backward compatibility' options available that are no longer what might be called 'best practice'. Plus you have to have a clear view on what your practice is! Most folk appear to use LF for eol in the repo (text files), and then convert them to local eol on export (and vice versa on add/commit). If you have got to a situation where "your" repo has mixed eol types, then you, and the whole project, will probably need a specific commit point where the repo is normalised ( "-Xrenormalize" ) to whatever the project decision is. Plus the project decision needs to identify what the user config settings should be on the different platforms - so that every one can smoothly switch to the new easy-to-use method. If you want, have a look at the main git list [1,2] for "CRLF" to find the various discussions. Torsten has continued to work the issue. As a general point, it is worth separating out the different whitespace errors, as the eol is just one particular issue. The space/tab/etc at end of line is another, and then tab vs space indentation (for those still using teletypes[3], it's 8 spaces per 1" tab!). -- Philip [1] http://public-inbox.org/git [2] http://public-inbox.org/git/20161130170232.19685-1-tbo...@web.de/ Torsten Bögershausen Wed, 30 Nov 2016, "-Xrenormalize" [3] https://en.wikipedia.org/wiki/Teletype_Model_33 https://en.wikipedia.org/wiki/Teleprinter ----- Original Message ----- From: Igor Djordjevic To: Git for human beings Sent: Friday, December 23, 2016 12:21 AM Subject: [git-users] git-apply: do not show *inherited* whitespace errors? Hi to all, I`m using Git for Windows mainly for now, where the issue is probably more (or only) pronounced, yet I kind of feel this might be of interest across platforms (for Git in general), as it makes cross-platform collaboration harder than it needs to be (or so it seems to me). I`m posting here and not on the main Git mailing list as this topic might be very well elaborated till now, so not to produce unnecessary noise there. When creating a patch, Git exports line endings as they are in the file (usually CR+LF on Windows), yet when you apply the patch, it warns you of "whitespace errors" (caused by CR part) - even though no whitespace actually changed (both old and new hunk have the same CR+LF line endings). Now, I may understand that in Unix world there was a need to consider anything other than LF line ending a "whitespace error" which should be reported accordingly, but with Git being widely used across platforms nowadays it seems it should know a bit better now, especially when line endings *didn`t change in the first place*. But even worse, if I change the patch file line endings manually to LF and git-apply the patch like that - no warning is given, even though line endings are in fact different now! I`m aware of --ws-error-highlight setting for git-diff, allowing to show/compare line endings between old/new lines, but manual line comparison seems rather impractical in case of applying multiple patches - and yet real whitespace errors (actually introduced with the patch we`re applying) are lost in the noise (or worse, not even reported, as in CR+LF to LF conversion). Current git-apply --whitespace options seem to allow for a variety of settings, but none to warn about *new* whitespace errors *only*, or even more important - about line ending changes in general (as converting from CRLF to LF might be considered a whitespace error situation, even though general Git thinks differently at the moment, probably assuming you actually corrected an existing whitespace error... :P). So, what are the thoughts on this? Would having an additional --whitespace option (like "preserve", "warn-new", "warn-changed", or something) to warn about *new* whitespace errors *only* make sense in general? Seems so to me, but yet as I`m still new around, I might be missing a bigger picture... p.s. Please let me know if you think this should be reposted to main Git mailing list (or to Git for Windows one, even). Thanks, BugA -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
