On Sat, Oct 15, 2011 at 11:41 AM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Sat, Oct 15, 2011 at 9:23 AM, Nico Kadel-Garcia <nkadel_at_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.
Received on 2011-10-16 00:37:20 CEST