Re: git-svn bridge and line endings

[Lucian Smith <lucianoelsmitho@gmail.com>]

On Tue, Aug 23, 2016 at 9:43 AM, Torsten Bögershausen <tboegi@web.de> wrote:
> On Mon, Aug 22, 2016 at 05:04:47PM -0700, Lucian Smith wrote:
>> I'm attempting to use the git-svn bridge, and am having problems with
>> line endings on Windows.
>>
>> The setup is that we have a git repository on github, and I've checked
>> out a branch on my Windows machine using Tortoise svn.  I make
>> changes, commit them, and the branch is updated.  In general, this
>> works fine.
>
> Just to make sure:
> The repo is in git format.
> Is it a public repo ?

Yes, it is.  In fact, it's https://github.com/sbmlteam/sbml-test-suite

> Or could you make a piblic demo repo ?
> Do I understand it right: Tortoise SVN talks directly to the Git server ?

This is the part that is a little bit of black magic for me, but yes:
I point TortoiseSVN at
https://github.com/sbmlteam/test-suite.git/branches/develop and tell
it to check that out, update, commit, etc.

> Isn't Tortoise SVN a client to talk to SVN server?
> What goes over the wire to the remote Git server, git or SVN ?

That's a good question ;-)  I think SVN!

> To my understanding, "git svn" can use Git locally, and talk to an SVN server.
> What do I miss ?

I assume something is using "git svn" on the github side of things,
but I don't know for sure, and I'm not sure who's in charge of that,
either.

-Lucian

>> If this was just SVN, I could set the 'eol-style' for files to
>> 'native' to let it know to expect Windows/linux/mac line endings for
>> particular files.  This seems to be handled in git by using the
>> '.gitattributes' file instead.  Unfortunately, the git/svn bridge
>> doesn't seem to be translate the information in the .gitattributes
>> file to appropriate eol-style settings in SVN.  Checking out a file
>> using SVN on Windows leaves me with a file without CRLF's, and if I
>> check in a CRLF file, that's the way it goes into the repository.
>> Differences in CRLF alone show up as 'real' differences that can be
>> checked in, and, if this happens, this causes problems with other
>> people's repositories.
>>
>> Am I doing something wrong; is there another way to handle this; or
>> can I file this as a bug report/feature request?
>