On Sat, Oct 15, 2011 at 11:41 AM, Les Mikesell <lesmikes...@gmail.com> wrote: > On Sat, Oct 15, 2011 at 9:23 AM, Nico Kadel-Garcia <nka...@gmail.com> wrote: >> >> Perhaps a better approach, especially if you know people will be using >> git-svn, is to review the repository for any files that use svn:eol, >> and *turn that off*, with a check that the binary EOL is the format >> you want. Then put in a pre-commit hook to prevent anyone using it. > > But a binary EOL is almost never works for cross platfom text. Which > is why systems designed for cross platform work do the conversions. > How do git users deal with it?
[ Allow me to put on my lecture hat. ] You've made me think about this, thank you. I can't speak for all git users: I use what tools work, and that's sometimes Subversion and sometimes git (for reasons I won't go into here). This is one of the things I prefer about git. Cross-platform source control systems which try to do this EOL handling for you *break*, predictably. It used to drive me bugfutz with CVS. By git standards, the file being checked out on one machine should match the code being checked out on the other machine in every byte. If you need to transform it to use it locally, that's a build environment issue, *not* a source control one. Treating it as a source control issue breaks things and, in my opinion, shoudl be deprecated, the same way that the ftp "text" format is also deprecated. The git model for EOL is safer, to my mind, because it is *predictable*. You know what you're going to get when you do a checkout. If you need to, you can have a local transformation utility for yet another "clone" that does not ever have to be transmitted back and corrupt the central repository. It can push to a staging git repository where these discrepancies can be resolved, and never corrupt the "mastter" repository. The Subversion model "you have to set svn:eol" is workable for a few isolated cases, but should be used only with caution. It should *never* be applied to a source tree: the risk of precisely this kind of mismatched working environment is too frequent. I've loathed having to enforce it for default checkins, which I've enountered, because it contributes to just the kind of sourcecode madness we just saw.