On Thursday, August 8, 2013 7:58:47 AM UTC-7, Niall Douglas wrote:
They're intended to be viewed as images, they should never be edited as source as they're script generated.
Well, then why have they mixed eols? Can the script be fixed? And I guess I can edited them using inkscape ;-)
You could edit then in Inkscape, and I'm sure that would work just fine regardless of the line-endings they use.
The question is what should the script be fixed to? I guess all \n's and no \r's is safest?
There is something real weird going on, as supposedly git should rationalize mismatched EOLs during a svn commit replay irrespective of mismatch in the svn content.
If by “svn commit replay” you mean what Boost2Git is doing, then no, there’s no reason to think that should happen. We’re using git-fast-import, which just eats the raw bytes you send it and doesn’t have an opinion about whether they’re text or not. Also, let me be very clear, just in case there’s some misunderstanding about this: it is not Boost2Git’s job to fix bad SVN commits in the past. If something like that needs to be fixed before the transition, it should be fixed by making new commits to SVN, which means existing history stays as it is. Another option is to make fixes in Git immediately after the transition (which again, doesn’t change history). That means the only things we can alter that change the way history appears in Git are .gitattributes, repositories.txt, etc., and non-Boost-specific logic in the Boost2Git source code—at least, not without very extensive justification.