Alexandre Garnier writes:
> Indeed, when changing the gitattributes for '* text', the replacement is OK.
OK. Earlier I said:
>> But it would be a bug if the same thing happens when the user
>> explicitly tells us that the file has CRLF line endings, and I
>> suspect we have that bug, which may
Indeed, when changing the gitattributes for '* text', the replacement is OK.
Thanks for all the explanations.
At first, my use case was some source files (imported from another
VCS) with CR in different contexts:
- lines ending with CRCRLF
- all content in LF or CRLF but some CR that should be E
On 2015-04-21 15.51, Alexandre Garnier wrote:
> Here is a test:
>
> git init -q crlf-test
> cd crlf-test
> echo '* text=auto' > .gitattributes
> git add .gitattributes
> git commit -q -m "Normalize EOL"
> echo -ne 'some content\r\nother \rcontent with CR\r\ncontent\r\nagain
> content with\r\
Alexandre Garnier writes:
> echo '* text=auto' > .gitattributes
> git add .gitattributes
> git commit -q -m "Normalize EOL"
> echo -ne 'some content\r\nother \rcontent with CR\r\ncontent\r\nagain
With text=auto, the user instructs us to guess, and we expect either
LF or CRLF line-terminate
Here is a test:
git init -q crlf-test
cd crlf-test
echo '* text=auto' > .gitattributes
git add .gitattributes
git commit -q -m "Normalize EOL"
echo -ne 'some content\r\nother \rcontent with CR\r\ncontent\r\nagain
content with\r\r\n' > inline-cr.txt
echo "Working directory content:"
cat -A in
5 matches
Mail list logo
