{"thread":{"id":"38389","subject":".gitattributes on branch behaves unexpected. Should it be more stateless?","startedAt":"2015-01-17T10:05:13Z","lastAt":"2015-01-21T19:27:46Z","messageCount":4,"participants":["Max W","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"254849","messageId":"CAGJ-DzH0meYgpE8My+UW4wbTxs6vo=wrgo0o21Lzh5Hg38ibEQ@mail.gmail.com","threadId":"38389","inReplyTo":null,"subject":".gitattributes on branch behaves unexpected. Should it be more stateless?","fromName":"Max W","fromEmail":"max.w.7777777@googlemail.com","sentAt":"2015-01-17T10:05:13Z","receivedAt":"2015-01-17T10:05:13Z","isPatch":false,"sender":{"key":"max.w.7777777@googlemail.com","avatar":null},"body":"Hi,\n\nI am asking myself if git and .gitattributes should be more stateless? i.e.\nwhatever you have done before is irrelevant, when you reach status XYZ with your\ngit repo, it is EXACTLY and BINARY the same all the time and everywhere.\n\nIt took some time for me to figure out, that depending on HOW you clone, the\nresulting local repo may differ. I did not expect this. I assumed that when I\nclone, it is a clone (meaning: 100% identical). And that the things I have done\nin my local repo before, don't have any relevance at all.\n\n\n\n** How to reproduce **\n1) create a repo, add a file with LF ending, add a .gitattributes telling git to\n   do a CRLF conversion\n2) clone the repo\n3) on brach development, change .gitattributes to LF\n4) clone again\n5) clone again, directly onto the branch development (git clone -b)\n\n\n** Expected result, (I) **\nclone 2) and original repo 1) are bytewise identical\n\n** Actual result (I) **\nclone 2) and original repo 1) differ, 1) has LF, 2) has CRLF\nas I have been warned before, I am (more or less) fine/OK with this\n\n\n** Expected result, (II) **\n- clone without -b (4) and clone with -b (5) are bytewise identical\n- I would have expected, that whatever I do, as soon as I have a clone and I am\n  on branch \"development\", my file should be LF\n- I would have expected, that HOW you clone is irrelevant\n\n** Actual result (II) **\nwithout -b (4) I have a CRLF file on my disk. with -b (5) I have a LF file on my\ndisk. The clones are not bytewise indentical. It appears as if the\n.gitattributes in branch development does not have any reliable effect.\n\n\n\nA potential solution might be be that\n- checkout\n- commit (a modified .gitattribues)\n- <further git commands>\n  do change the files in the local repo.\nAs of now my understanding is that this is not how .gitattributes (or\n.gitignore) are designed. .gitattributes only has influence on pushing/fetching.\n\nI don't know if and which side effects would occur if this design would be\nchanged. Hence I am glad to hear any feedback on the issue described above. And\nyes, I agree that this is a minor issue and that all .gitattribute things are\nkind of edge cases.\n\nThanks and with best regards,\nMax\n\n\n\n\n\n\n1)\nmkdir git-bug-or-feature\ncd git-bug-or-feature\ngit init\necho \"foo.bar eol=crlf\" > .gitattributes\necho \"hello world\" > foo.bar\ngit add .\ngit commit -m \"now crlf\"\n# [master (root-commit) 7f3f6b0] now crlf\n# warning: LF will be replaced by CRLF in foo.bar.\n# The file will have its original line endings in your working directory.\nfile foo.bar\n# foo.bar: ASCII text\ncd ..\n\n2)\ngit clone git-bug-or-feature git-bug-or-feature_clone\ncd git-bug-or-feature_clone\nfile foo.bar\n# foo.bar: ASCII text, with CRLF line terminators\ncd ..\nrm -rf git-bug-or-feature_clone\n\n3)\ncd git-bug-or-feature\ngit branch development\ngit checkout development\necho \"foo.bar eol=lf\" > .gitattributes\ngit add .\ngit commit -m \"now lf on branch development\"\nfile foo.bar\n# foo.bar: ASCII text\ngit checkout master\nfile foo.bar\n# foo.bar: ASCII text\ncd ..\n\n4)\ngit clone git-bug-or-feature git-bug-or-feature_clone\ncd git-bug-or-feature_clone\nfile foo.bar\n"},{"id":"254852","messageId":"B551DC4135DC4DA3B8BA5E1BBA36BBEC@PhilipOakley","threadId":"38389","inReplyTo":"CAGJ-DzH0meYgpE8My+UW4wbTxs6vo=wrgo0o21Lzh5Hg38ibEQ@mail.gmail.com","subject":"Re: .gitattributes on branch behaves unexpected. Should it be more stateless?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2015-01-17T11:18:51Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"> Hi,\n>\n> I am asking myself if git and .gitattributes should be more stateless? \n> i.e.\n> whatever you have done before is irrelevant, when you reach status XYZ \n> with your\n> git repo, it is EXACTLY and BINARY the same all the time and \n> everywhere.\n>\n> It took some time for me to figure out, that depending on HOW you \n> clone, the\n> resulting local repo may differ. I did not expect this. I assumed that \n> when I\n> clone, it is a clone (meaning: 100% identical). And that the things I \n> have done\n> in my local repo before, don't have any relevance at all.\n>\n\nYou don't say which parts you believe should be identical, nor why.\n\nInternally Git can represent its object store in many ways based on some \nobjects being 'loose' and some objects being 'packed'. However both \nstyles of representation are of the same base objects and their \ncontents.\n\nThen we have external OS representation, in particular the end of line \nrepresentations between the three main OS types Win/Mac/'nix. Git gives \n_you_ the ability the use any of these representations for the same base \nobjects. Thus the object file with text \"Hello World/EOL/Goodbye World\" \nwill have three different binary representations once you export them to \nthe selected file system type (according to you .gitattributes \nsettings).\n\nIf you always select LF endings for text files (both on the way in and \non the way out of the repo), then you will get identical files on the \ndifferent clones. Git has many settings for personalisation.\n\nDoes that help?\n\n>\n>\n> ** How to reproduce **\n> 1) create a repo, add a file with LF ending, add a .gitattributes \n> telling git to\n>   do a CRLF conversion\n> 2) clone the repo\n> 3) on brach development, change .gitattributes to LF\n> 4) clone again\n> 5) clone again, directly onto the branch development (git clone -b)\n>\n>\n> ** Expected result, (I) **\n> clone 2) and original repo 1) are bytewise identical\n>\n> ** Actual result (I) **\n> clone 2) and original repo 1) differ, 1) has LF, 2) has CRLF\n> as I have been warned before, I am (more or less) fine/OK with this\n>\n>\n> ** Expected result, (II) **\n> - clone without -b (4) and clone with -b (5) are bytewise identical\n> - I would have expected, that whatever I do, as soon as I have a clone \n> and I am\n>  on branch \"development\", my file should be LF\n> - I would have expected, that HOW you clone is irrelevant\n>\n> ** Actual result (II) **\n> without -b (4) I have a CRLF file on my disk. with -b (5) I have a LF \n> file on my\n> disk. The clones are not bytewise indentical. It appears as if the\n> .gitattributes in branch development does not have any reliable \n> effect.\n>\n>\n>\n> A potential solution might be be that\n> - checkout\n> - commit (a modified .gitattribues)\n> - <further git commands>\n>  do change the files in the local repo.\n> As of now my understanding is that this is not how .gitattributes (or\n> .gitignore) are designed. .gitattributes only has influence on \n> pushing/fetching.\n>\n> I don't know if and which side effects would occur if this design \n> would be\n> changed. Hence I am glad to hear any feedback on the issue described \n> above. And\n> yes, I agree that this is a minor issue and that all .gitattribute \n> things are\n> kind of edge cases.\n>\n> Thanks and with best regards,\n> Max\n>\n>\n>\n>\n>\n>\n> 1)\n> mkdir git-bug-or-feature\n> cd git-bug-or-feature\n> git init\n> echo \"foo.bar eol=crlf\" > .gitattributes\n> echo \"hello world\" > foo.bar\n> git add .\n> git commit -m \"now crlf\"\n> # [master (root-commit) 7f3f6b0] now crlf\n> # warning: LF will be replaced by CRLF in foo.bar.\n> # The file will have its original line endings in your working \n> directory.\n> file foo.bar\n> # foo.bar: ASCII text\n> cd ..\n>\n> 2)\n> git clone git-bug-or-feature git-bug-or-feature_clone\n> cd git-bug-or-feature_clone\n> file foo.bar\n> # foo.bar: ASCII text, with CRLF line terminators\n> cd ..\n> rm -rf git-bug-or-feature_clone\n>\n> 3)\n> cd git-bug-or-feature\n> git branch development\n> git checkout development\n> echo \"foo.bar eol=lf\" > .gitattributes\n> git add .\n> git commit -m \"now lf on branch development\"\n> file foo.bar\n> # foo.bar: ASCII text\n> git checkout master\n> file foo.bar\n> # foo.bar: ASCII text\n> cd ..\n>\n> 4)\n> git clone git-bug-or-feature git-bug-or-feature_clone\n> cd git-bug-or-feature_clone\n> file foo.bar\n> --\nphilip \n"},{"id":"254869","messageId":"CAGJ-DzFos0DHNettfSHp0HfCGKqC8agvqELezi6HLqWpob5f_g@mail.gmail.com","threadId":"38389","inReplyTo":"B551DC4135DC4DA3B8BA5E1BBA36BBEC@PhilipOakley","subject":"Re: .gitattributes on branch behaves unexpected. Should it be more stateless?","fromName":"Max W","fromEmail":"max.w.7777777@googlemail.com","sentAt":"2015-01-18T17:14:27Z","receivedAt":"2015-01-18T17:14:27Z","isPatch":false,"sender":{"key":"max.w.7777777@googlemail.com","avatar":null},"body":"Hi philip,\n\nthanks for your reply.\n\n> You don't say which parts you believe should be identical, nor why.\nI expected my representation to be identical, nevertheless what path\nI have taken to come there. e.g.\ngit clone -b <branch>\ngit clone; git checkout <branch>\nshould result in a binary-indentical representation of the files\ntracked by git. But they don't.\n\nWhy did I expect this? Good question. Feels more intuitive for me.\nLike \"don't worry what you have done before. When your HEAD is on a\ncertain commit, git will make sure all your files in your filesystem\nare they way you (and the other committers) want them to be\".\n\n> [..]\n> Does that help?\nYes, it helped me to distinguish better between data and representation.\nNew understanding: .gitattributes determines how to represent data.\n\nAs .gitattributes is under git control there can be 2 versions of\n.gitattributes in 2 branches. So I can tell git\n- on branch foo with gitattributes * eol=LF show me all files with LF\n- on branch bar with gitattributes * eol=CRLF show me all files with CRLF\nBut this doesn't work. The representation of the files is\ndetermined/depending on how I cloned or fetched the repo. A \"git checkout\nbar\" does not change the representation.\n\nDoes this help to show where my concerns / my issue is?\n\nBest Regards,\nMax\n\n\n\n2015-01-17 14:16 GMT+01:00 Philip Oakley <philipoakley@iee.org>:\n>> Hi,\n>>\n>> I am asking myself if git and .gitattributes should be more stateless?\n>> i.e.\n>> whatever you have done before is irrelevant, when you reach status XYZ\n>> with your\n>> git repo, it is EXACTLY and BINARY the same all the time and everywhere.\n>>\n>> It took some time for me to figure out, that depending on HOW you clone,\n>> the\n>> resulting local repo may differ. I did not expect this. I assumed that\n>> when I\n>> clone, it is a clone (meaning: 100% identical). And that the things I have\n>> done\n>> in my local repo before, don't have any relevance at all.\n>>\n>\n> You don't say which parts you believe should be identical, nor why.\n>\n> Internally Git can represent its object store in many ways based on some\n> objects being 'loose' and some objects being 'packed'. However both styles\n> of representation are of the same base objects and their contents.\n>\n> Then we have external OS representation, in particular the end of line\n> representations between the three main OS types Win/Mac/'nix. Git gives\n> _you_ the ability the use any of these representations for the same base\n> objects. Thus the object file with text \"Hello World/EOL/Goodbye World\" will\n> have three different binary representations once you export them to the\n> selected file system type (according to you .gitattributes settings).\n>\n> If you always select LF endings for text files (both on the way in and on\n> the way out of the repo), then you will get identical files on the different\n> clones. Git has many settings for personalisation.\n>\n> Does that help?\n>\n>>\n>>\n>> ** How to reproduce **\n>> 1) create a repo, add a file with LF ending, add a .gitattributes telling\n>> git to\n>>   do a CRLF conversion\n>> 2) clone the repo\n>> 3) on brach development, change .gitattributes to LF\n>> 4) clone again\n>> 5) clone again, directly onto the branch development (git clone -b)\n>>\n>>\n>> ** Expected result, (I) **\n>> clone 2) and original repo 1) are bytewise identical\n>>\n>> ** Actual result (I) **\n>> clone 2) and original repo 1) differ, 1) has LF, 2) has CRLF\n>> as I have been warned before, I am (more or less) fine/OK with this\n>>\n>>\n>> ** Expected result, (II) **\n>> - clone without -b (4) and clone with -b (5) are bytewise identical\n>> - I would have expected, that whatever I do, as soon as I have a clone and\n>> I am\n>>  on branch \"development\", my file should be LF\n>> - I would have expected, that HOW you clone is irrelevant\n>>\n>> ** Actual result (II) **\n>> without -b (4) I have a CRLF file on my disk. with -b (5) I have a LF file\n>> on my\n>> disk. The clones are not bytewise indentical. It appears as if the\n>> .gitattributes in branch development does not have any reliable effect.\n>>\n>>\n>>\n>> A potential solution might be be that\n>> - checkout\n>> - commit (a modified .gitattribues)\n>> - <further git commands>\n>>  do change the files in the local repo.\n>> As of now my understanding is that this is not how .gitattributes (or\n>> .gitignore) are designed. .gitattributes only has influence on\n>> pushing/fetching.\n>>\n>> I don't know if and which side effects would occur if this design would be\n>> changed. Hence I am glad to hear any feedback on the issue described\n>> above. And\n>> yes, I agree that this is a minor issue and that all .gitattribute things\n>> are\n>> kind of edge cases.\n>>\n>> Thanks and with best regards,\n>> Max\n>>\n>>\n>>\n>>\n>>\n>>\n>> 1)\n>> mkdir git-bug-or-feature\n>> cd git-bug-or-feature\n>> git init\n>> echo \"foo.bar eol=crlf\" > .gitattributes\n>> echo \"hello world\" > foo.bar\n>> git add .\n>> git commit -m \"now crlf\"\n>> # [master (root-commit) 7f3f6b0] now crlf\n>> # warning: LF will be replaced by CRLF in foo.bar.\n>> # The file will have its original line endings in your working directory.\n>> file foo.bar\n>> # foo.bar: ASCII text\n>> cd ..\n>>\n>> 2)\n>> git clone git-bug-or-feature git-bug-or-feature_clone\n>> cd git-bug-or-feature_clone\n>> file foo.bar\n>> # foo.bar: ASCII text, with CRLF line terminators\n>> cd ..\n>> rm -rf git-bug-or-feature_clone\n>>\n>> 3)\n>> cd git-bug-or-feature\n>> git branch development\n>> git checkout development\n>> echo \"foo.bar eol=lf\" > .gitattributes\n>> git add .\n>> git commit -m \"now lf on branch development\"\n>> file foo.bar\n>> # foo.bar: ASCII text\n>> git checkout master\n>> file foo.bar\n>> # foo.bar: ASCII text\n>> cd ..\n>>\n>> 4)\n>> git clone git-bug-or-feature git-bug-or-feature_clone\n>> cd git-bug-or-feature_clone\n>> file foo.bar\n>> --\n>\n> philip\n"},{"id":"255027","messageId":"F0A5C841474A4CEEB51C8F8487357189@PhilipOakley","threadId":"38389","inReplyTo":"CAGJ-DzFos0DHNettfSHp0HfCGKqC8agvqELezi6HLqWpob5f_g@mail.gmail.com","subject":"Re: .gitattributes on branch behaves unexpected. Should it be more stateless?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2015-01-21T19:27:46Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Please, no top posting. It breaks the discussion flow.\nFrom: \"Max W\" <max.w.7777777@googlemail.com>\n> Hi philip,\n>\n> thanks for your reply.\n>\n>> You don't say which parts you believe should be identical, nor why.\n> I expected my representation to be identical, nevertheless what path\n> I have taken to come there. e.g.\n> git clone -b <branch>\n> git clone; git checkout <branch>\n> should result in a binary-indentical representation of the files\n> tracked by git. But they don't.\n\nDon't forget that some of the EOL setting are also in the git config \nfile(s) [global, system, local] so there may be differences from them.\n\nUse 'git cat-file' to get the plumbing level view of the cannonical \nobject content.\n\nI am prtesuming that the ONLY differences you are seeing are end of line \nconversion changes for checkout. Is that correct.\n\nAre there other whitespace changes happening? Is that on the way into \nthe repo (git add). There are some white space settings available.\n\nThe other aspect maybe language coding settings (utf8, iso...., cp-..., \netc).\n\nOr is it even more than that? (Your first email suggested it was just \nline endings)\n\nThe discussion may be better helped on the googlegroups git-users forum \ngit-users@googlegroups.com if this is more of a 'getting started with \nGit' problem.\n\n>\n> Why did I expect this? Good question. Feels more intuitive for me.\n> Like \"don't worry what you have done before. When your HEAD is on a\n> certain commit, git will make sure all your files in your filesystem\n> are they way you (and the other committers) want them to be\".\n>\n>> [..]\n>> Does that help?\n> Yes, it helped me to distinguish better between data and \n> representation.\n> New understanding: .gitattributes determines how to represent data.\n>\n> As .gitattributes is under git control there can be 2 versions of\n> .gitattributes in 2 branches. So I can tell git\n> - on branch foo with gitattributes * eol=LF show me all files with LF\n> - on branch bar with gitattributes * eol=CRLF show me all files with \n> CRLF\n> But this doesn't work. The representation of the files is\n> determined/depending on how I cloned or fetched the repo. A \"git \n> checkout\n> bar\" does not change the representation.\n>\n> Does this help to show where my concerns / my issue is?\n>\n> Best Regards,\n> Max\n>\n>\n>\n> 2015-01-17 14:16 GMT+01:00 Philip Oakley <philipoakley@iee.org>:\n>>> Hi,\n>>>\n>>> I am asking myself if git and .gitattributes should be more \n>>> stateless?\n>>> i.e.\n>>> whatever you have done before is irrelevant, when you reach status \n>>> XYZ\n>>> with your\n>>> git repo, it is EXACTLY and BINARY the same all the time and \n>>> everywhere.\n>>>\n>>> It took some time for me to figure out, that depending on HOW you \n>>> clone,\n>>> the\n>>> resulting local repo may differ. I did not expect this. I assumed \n>>> that\n>>> when I\n>>> clone, it is a clone (meaning: 100% identical). And that the things \n>>> I have\n>>> done\n>>> in my local repo before, don't have any relevance at all.\n>>>\n>>\n>> You don't say which parts you believe should be identical, nor why.\n>>\n>> Internally Git can represent its object store in many ways based on \n>> some\n>> objects being 'loose' and some objects being 'packed'. However both \n>> styles\n>> of representation are of the same base objects and their contents.\n>>\n>> Then we have external OS representation, in particular the end of \n>> line\n>> representations between the three main OS types Win/Mac/'nix. Git \n>> gives\n>> _you_ the ability the use any of these representations for the same \n>> base\n>> objects. Thus the object file with text \"Hello World/EOL/Goodbye \n>> World\" will\n>> have three different binary representations once you export them to \n>> the\n>> selected file system type (according to you .gitattributes settings).\n>>\n>> If you always select LF endings for text files (both on the way in \n>> and on\n>> the way out of the repo), then you will get identical files on the \n>> different\n>> clones. Git has many settings for personalisation.\n>>\n>> Does that help?\n>>\n>>>\n>>>\n>>> ** How to reproduce **\n>>> 1) create a repo, add a file with LF ending, add a .gitattributes \n>>> telling\n>>> git to\n>>>   do a CRLF conversion\n>>> 2) clone the repo\n>>> 3) on brach development, change .gitattributes to LF\n>>> 4) clone again\n>>> 5) clone again, directly onto the branch development (git clone -b)\n>>>\n>>>\n>>> ** Expected result, (I) **\n>>> clone 2) and original repo 1) are bytewise identical\n>>>\n>>> ** Actual result (I) **\n>>> clone 2) and original repo 1) differ, 1) has LF, 2) has CRLF\n>>> as I have been warned before, I am (more or less) fine/OK with this\n>>>\n>>>\n>>> ** Expected result, (II) **\n>>> - clone without -b (4) and clone with -b (5) are bytewise identical\n>>> - I would have expected, that whatever I do, as soon as I have a \n>>> clone and\n>>> I am\n>>>  on branch \"development\", my file should be LF\n>>> - I would have expected, that HOW you clone is irrelevant\n>>>\n>>> ** Actual result (II) **\n>>> without -b (4) I have a CRLF file on my disk. with -b (5) I have a \n>>> LF file\n>>> on my\n>>> disk. The clones are not bytewise indentical. It appears as if the\n>>> .gitattributes in branch development does not have any reliable \n>>> effect.\n>>>\n>>>\n>>>\n>>> A potential solution might be be that\n>>> - checkout\n>>> - commit (a modified .gitattribues)\n>>> - <further git commands>\n>>>  do change the files in the local repo.\n>>> As of now my understanding is that this is not how .gitattributes \n>>> (or\n>>> .gitignore) are designed. .gitattributes only has influence on\n>>> pushing/fetching.\n>>>\n>>> I don't know if and which side effects would occur if this design \n>>> would be\n>>> changed. Hence I am glad to hear any feedback on the issue described\n>>> above. And\n>>> yes, I agree that this is a minor issue and that all .gitattribute \n>>> things\n>>> are\n>>> kind of edge cases.\n>>>\n>>> Thanks and with best regards,\n>>> Max\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>> 1)\n>>> mkdir git-bug-or-feature\n>>> cd git-bug-or-feature\n>>> git init\n>>> echo \"foo.bar eol=crlf\" > .gitattributes\n>>> echo \"hello world\" > foo.bar\n>>> git add .\n>>> git commit -m \"now crlf\"\n>>> # [master (root-commit) 7f3f6b0] now crlf\n>>> # warning: LF will be replaced by CRLF in foo.bar.\n>>> # The file will have its original line endings in your working \n>>> directory.\n>>> file foo.bar\n>>> # foo.bar: ASCII text\n>>> cd ..\n>>>\n>>> 2)\n>>> git clone git-bug-or-feature git-bug-or-feature_clone\n>>> cd git-bug-or-feature_clone\n>>> file foo.bar\n>>> # foo.bar: ASCII text, with CRLF line terminators\n>>> cd ..\n>>> rm -rf git-bug-or-feature_clone\n>>>\n>>> 3)\n>>> cd git-bug-or-feature\n>>> git branch development\n>>> git checkout development\n>>> echo \"foo.bar eol=lf\" > .gitattributes\n>>> git add .\n>>> git commit -m \"now lf on branch development\"\n>>> file foo.bar\n>>> # foo.bar: ASCII text\n>>> git checkout master\n>>> file foo.bar\n>>> # foo.bar: ASCII text\n>>> cd ..\n>>>\n>>> 4)\n>>> git clone git-bug-or-feature git-bug-or-feature_clone\n>>> cd git-bug-or-feature_clone\n>>> file foo.bar\n>>> --\n>>\n>> philip\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n"}]}