On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote: > > I don't think a solution will be found by declaring one platform > native (UNIX) and all other platform non-native. The question to > answer is how to support cross-platform projects. A valid > solution should never corrupt data unless the user explicitly > told git to do so. I don't believe it is a valid solution to set > core.autocrlf=true on Windows and tell the users: "Well, in its > default settings, git sometimes corrupts your data on Windows. > Maybe you want to switch to Linux because this is the native > platform where data corruption will never happen." Maybe I am wrong but it seems to me that to guarantee that CRLF conversion is reversible (which means that you can always get exactly what you put into the repository), it is enough to check that the conversation is performed only if every LF is preceded by CR. If it is not so, error out and tell the user that the file should be either marked as binary or EOL in the text must be corrected. So, even in those rare cases where the heuristic went wrong, you will not lose your data. Most likely you will get the above error, but even if a binary file is checked in as text, it will affect only cross-platform projects, and it will be easily to correct the situation later by marking this file as binary and checking in again. So, it is a extermely rare event, and no data is lost. Perhaps, this option can be called core.autocrlf=safe IMHO, a _text_ file is not just some octets, it consists of lines. Even without CRLF conversation, Git is aware about to do some basic operations like diff and merge. So, it is natural to store lines in the repository in the same EOL marker regardless on what platform the file is created. So, having core.autocrlf=false on Windows is wrong. You may not notice it until you do not move to another platform, but the whole thing is already broken. It is not about one platform being more native than other. It is like in the C standard, LF is used to denote the end of line, because it is the only sane choice to mark it. Dmitry - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
