I would assume that none of this crlf stuff exists at all on Linux /
Unix / Posix, so if done right has zero impact outside of the Windows
nuthouse. Inside that, folks are already so used to incredible slowness
in file I/O that I'm not sure the round tripping I suggest as a check
would be very noticeable, but in any case I fully agree it should be
optional even there. However, if git could support something that never
screws up, absolutely guaranteeing data integrity in the presence of
these transforms, that would be a first in this arena and I believe a
significant selling point.
Mark
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html