Hi, I am asking myself if git and .gitattributes should be more stateless? i.e. whatever you have done before is irrelevant, when you reach status XYZ with your git repo, it is EXACTLY and BINARY the same all the time and everywhere. It took some time for me to figure out, that depending on HOW you clone, the resulting local repo may differ. I did not expect this. I assumed that when I clone, it is a clone (meaning: 100% identical). And that the things I have done in my local repo before, don't have any relevance at all. ** How to reproduce ** 1) create a repo, add a file with LF ending, add a .gitattributes telling git to do a CRLF conversion 2) clone the repo 3) on brach development, change .gitattributes to LF 4) clone again 5) clone again, directly onto the branch development (git clone -b) ** Expected result, (I) ** clone 2) and original repo 1) are bytewise identical ** Actual result (I) ** clone 2) and original repo 1) differ, 1) has LF, 2) has CRLF as I have been warned before, I am (more or less) fine/OK with this ** Expected result, (II) ** - clone without -b (4) and clone with -b (5) are bytewise identical - I would have expected, that whatever I do, as soon as I have a clone and I am on branch "development", my file should be LF - I would have expected, that HOW you clone is irrelevant ** Actual result (II) ** without -b (4) I have a CRLF file on my disk. with -b (5) I have a LF file on my disk. The clones are not bytewise indentical. It appears as if the .gitattributes in branch development does not have any reliable effect. A potential solution might be be that - checkout - commit (a modified .gitattribues) - <further git commands> do change the files in the local repo. As of now my understanding is that this is not how .gitattributes (or .gitignore) are designed. .gitattributes only has influence on pushing/fetching. I don't know if and which side effects would occur if this design would be changed. Hence I am glad to hear any feedback on the issue described above. And yes, I agree that this is a minor issue and that all .gitattribute things are kind of edge cases. Thanks and with best regards, Max 1) mkdir git-bug-or-feature cd git-bug-or-feature git init echo "foo.bar eol=crlf" > .gitattributes echo "hello world" > foo.bar git add . git commit -m "now crlf" # [master (root-commit) 7f3f6b0] now crlf # warning: LF will be replaced by CRLF in foo.bar. # The file will have its original line endings in your working directory. file foo.bar # foo.bar: ASCII text cd .. 2) git clone git-bug-or-feature git-bug-or-feature_clone cd git-bug-or-feature_clone file foo.bar # foo.bar: ASCII text, with CRLF line terminators cd .. rm -rf git-bug-or-feature_clone 3) cd git-bug-or-feature git branch development git checkout development echo "foo.bar eol=lf" > .gitattributes git add . git commit -m "now lf on branch development" file foo.bar # foo.bar: ASCII text git checkout master file foo.bar # foo.bar: ASCII text cd .. 4) git clone git-bug-or-feature git-bug-or-feature_clone cd git-bug-or-feature_clone file foo.bar -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html