Skip to content
This repository has been archived by the owner on Aug 8, 2024. It is now read-only.

Now UTF-16 handling EOL fixup patch #42

Open
wants to merge 1 commit into
base: ned14-bad_eol_fix
Choose a base branch
from

Conversation

ned14
Copy link
Member

@ned14 ned14 commented Sep 8, 2013

Passes the boost SVN Dave sent me. I now know why my boost svnsynced copy didn't fault - I didn't sync sandbox, and sandbox is what contains the UTF-16.

BTW a quick note: some of the warnings about having to convert EOL in some of the sandbox files refer to filenames saying something like "bad_end_of_line_test.txt". I am almost certain that files named like that have intentionally incorrect EOLs and they want them to stay that way.

I'd recommend those affected to not use .txt for such test files (which stops Boost2Git messing with the file), and it might be an idea to add a new "binary text" extension to gitattributes for that sort of file to ensure git doesn't try fiddling with the contents either during checkout.

Niall

@dabrahams
Copy link
Member

w.r.t. intentionally-bad line endings, you can just mark those specific filenames as binary in .gitattributes, can't you?

@ned14
Copy link
Member Author

ned14 commented Sep 8, 2013

@dabrahams You can add any glob matching said files to .gitattributes e.g. bad_eol_test*.txt or whatever. Full paths also qualify of course, but I'm thinking some wildcard pattern or special file extension to indicate deliberately malformed text would help users transition their files correctly. Even adding a .bin extension would be enough I think.

@ned14
Copy link
Member Author

ned14 commented Sep 15, 2013

How has this patchset fared? Does it solve the original problem successfully? Niall

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants