Hi to all, This is a follow-up of a message posted at git-users Google group[1], as the topic may actually be better suited for this mailing list instead. If needed, some elaboration on the context can be found there, as well as a detailed example describing the motive for the question itself (or directly here[2], second half of the message).
In short -- git-apply warns on applying the patch with CRLF line endings (new), considered whitespace errors, even when previous hunk version (old) has/had that very same CRLF line endings, too, so nothing actually changed in this regards. Even worse, it happily applies a patch with LF line endings (new) without any warning/hint, even though previous (old) line endings were CRLF, thus effectively (and silently) breaking the (previous) line endings. I understand that what should be considered "correct" line endings can be set explicitly (and should be communicated on the project level in the first place), but would it make sense to have an additional git-apply --whitespace option (like "warn-changed" and "error-changed", or something) to warn/fail on *changed* end of line *only*, without any further knowledge needed? So not to have Git need to assume or know which line endings should be considered "correct", nor to think/bother too much with it, but just to warn/fail on actual line ending *change* (in comparison between old and new part/hunk of the patch). This seems more intuitive to me, and much more cross-platform collaboration friendly, at least as an option, as one wouldn`t need to think much about "correct" project/file line endings (which would still be advised, anyway), but would be promptly warned about possibly breaking previous/existing line endings, maybe even with an option to keep those previous ones, or force the new ones... yet as I`m still new around, I accept that I might be missing some bigger picture here :) Thanks, BugA P.S. I`m discussing git-apply and end-of-line handling here in particular as that`s what I`m currently concerned with, and for the sake of simplicity, but might be that whole thing could theoretically be broadened to other Git tools (like git-diff) and whitespace (error) handling in general, too (warn/fail only if actually introduced in new hunk, not previously being present in the old one). -- [1] https://groups.google.com/d/msg/git-users/9Os_48yJdn0/j9S_W7h-EAAJ [2] https://groups.google.com/d/msg/git-users/9Os_48yJdn0/5S9Ja1fEEAAJ
