{"thread":{"id":"38711","subject":"Surprising interaction of \"binary\" and \"eol\" gitattributes","startedAt":"2015-03-05T16:38:28Z","lastAt":"2015-03-11T21:43:45Z","messageCount":17,"participants":["Michael Haggerty","Torsten Bögershausen","Junio C Hamano","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"257089","messageId":"54F88684.3020905@alum.mit.edu","threadId":"38711","inReplyTo":null,"subject":"Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2015-03-05T16:38:28Z","receivedAt":"2015-03-05T16:38:28Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"I would expect that the following .gitattributes file\n\n * eol=crlf\n *.png -text\n\nwould leave EOL translation turned off for PNG files. In other words, I\nwould expect that explicitly setting \"-text\" would take precedence over\nthe fact that setting \"eol\" implies that a file should be considered to\nbe \"text\".\n\nI would even more strongly expect\n\n * eol=crlf\n *.png binary\n\nto turn off EOL translation for PNG files.\n\nBut in fact, in both of the above cases, EOL translation is turned *on*\nfor PNG files.\n\nI propose that \"-text\" should override any setting for \"eol\" (which\nwould of course fix both problems, since \"binary\" is equivalent to\n\"-diff -merge -text\"). What do people think?\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\n"},{"id":"257103","messageId":"54F8C152.7010203@web.de","threadId":"38711","inReplyTo":"54F88684.3020905@alum.mit.edu","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-03-05T20:49:22Z","receivedAt":"2015-03-05T20:49:22Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2015-03-05 17.38, Michael Haggerty wrote:\n> I would expect that the following .gitattributes file\n> \n> * eol=crlf\n> *.png -text\n> \n> would leave EOL translation turned off for PNG files. In other words, I\n> would expect that explicitly setting \"-text\" would take precedence over\n> the fact that setting \"eol\" implies that a file should be considered to\n> be \"text\".\n> \n> I would even more strongly expect\n> \n> * eol=crlf\n> *.png binary\n> \n> to turn off EOL translation for PNG files.\n> \n> But in fact, in both of the above cases, EOL translation is turned *on*\n> for PNG files.\n> \n> I propose that \"-text\" should override any setting for \"eol\" (which\n> would of course fix both problems, since \"binary\" is equivalent to\n> \"-diff -merge -text\"). What do people think?\n> \n> Michael\n> \n\n(\"binary\" is not supported, we need \"-text\")\nBeside that, \n\n> * eol=crlf\n> *.png -text\nshould work as you describe.\n\nDo you think you make a test case for this ?\nIn best case as a real patch :-)\n\n(I know that attributes should take precedence over eol settings in the\nconfig file, and this is not always the case)\n"},{"id":"257110","messageId":"xmqqwq2v14iv.fsf@gitster.dls.corp.google.com","threadId":"38711","inReplyTo":"54F88684.3020905@alum.mit.edu","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-05T22:08:24Z","receivedAt":"2015-03-05T22:08:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> I would expect that the following .gitattributes file\n>\n> * eol=crlf\n> *.png -text\n>\n> would leave EOL translation turned off for PNG files. In other words, I\n> would expect that explicitly setting \"-text\" would take precedence over\n> the fact that setting \"eol\" implies that a file should be considered to\n> be \"text\".\n>\n> I would even more strongly expect\n>\n> * eol=crlf\n> *.png binary\n>\n> to turn off EOL translation for PNG files.\n>\n> But in fact, in both of the above cases, EOL translation is turned *on*\n> for PNG files.\n>\n> I propose that \"-text\" should override any setting for \"eol\" (which\n> would of course fix both problems, since \"binary\" is equivalent to\n> \"-diff -merge -text\"). What do people think?\n\nHmm, is there really something that needs a new proposal and\nopinions?\n\nThe way I read the flow in convert.c is:\n\n convert_to_git() uses input_crlf_action() to figure out what\n crlf_to_git() conversion is necessary.\n\n input_crlf_action() looks at text_attr and says CRLF_BINARY when\n it is CRLF_BINARY without looking at eol_attr at all.\n\n text_attr above is ca.crlf_action in convert_to_git().\n\n The whole ca.* comes from convert_attrs() inspecting attributes\n on the incoming path.\n\n convert_attrs() inspects \"eol\" and \"text\" attributes, among\n others, and sets crlf_action by calling git_path_check_crlf().\n\n git_path_check_crlf() looks at the 'text' attribute; if it is\n set to false, it returns CRLF_BINARY.\n\n crlf_to_git() when given crlf_action==CRLF_BINARY is a no-op.\n\nSo, with the above attributes where anything is eol=crlf by default\nand in addition *.png is binary (which contains -text), we shouldn't\nget any crlf munging. Am I reading/following the code incorrectly?\n\nPuzzled....\n"},{"id":"257129","messageId":"54F9422D.2020800@web.de","threadId":"38711","inReplyTo":"xmqqwq2v14iv.fsf@gitster.dls.corp.google.com","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-03-06T05:59:09Z","receivedAt":"2015-03-06T05:59:09Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 03/05/2015 11:08 PM, Junio C Hamano wrote:\n> Michael Haggerty writes:\n>\n>> I would expect that the following .gitattributes file\n>>\n>> * eol=crlf\n>> *.png -text\n>>\n>> would leave EOL translation turned off for PNG files. In other words, I\n>> would expect that explicitly setting \"-text\" would take precedence over\n>> the fact that setting \"eol\" implies that a file should be considered to\n>> be \"text\".\n>>\n>> I would even more strongly expect\n>>\n>> * eol=crlf\n>> *.png binary\n>>\n>> to turn off EOL translation for PNG files.\n>>\n>> But in fact, in both of the above cases, EOL translation is turned *on*\n>> for PNG files.\n>>\n>> I propose that \"-text\" should override any setting for \"eol\" (which\n>> would of course fix both problems, since \"binary\" is equivalent to\n>> \"-diff -merge -text\"). What do people think?\n> Hmm, is there really something that needs a new proposal and\n> opinions?\n>\n> The way I read the flow in convert.c is:\n>\n> convert_to_git() uses input_crlf_action() to figure out what\n> crlf_to_git() conversion is necessary.\n>\n> input_crlf_action() looks at text_attr and says CRLF_BINARY when\n> it is CRLF_BINARY without looking at eol_attr at all.\n>\n> text_attr above is ca.crlf_action in convert_to_git().\n>\n> The whole ca.* comes from convert_attrs() inspecting attributes\n> on the incoming path.\n>\n> convert_attrs() inspects \"eol\" and \"text\" attributes, among\n> others, and sets crlf_action by calling git_path_check_crlf().\n>\n> git_path_check_crlf() looks at the 'text' attribute; if it is\n> set to false, it returns CRLF_BINARY.\n>\n> crlf_to_git() when given crlf_action==CRLF_BINARY is a no-op.\n>\n> So, with the above attributes where anything is eol=crlf by default\n> and in addition *.png is binary (which contains -text), we shouldn't\n> get any crlf munging. Am I reading/following the code incorrectly?\n>\n> Puzzled....\n> --\n\nI need to admit that I can't reproduce it here,\nthe following should trigger it, but all test cases pass\n\n\ndiff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh\n\nindex 452320d..22f031d 100755\n--- a/t/t0027-auto-crlf.sh\n+++ b/t/t0027-auto-crlf.sh\n@@ -37,7 +37,8 @@ create_gitattributes () {\n echo \"*.txt text\" >.gitattributes\n ;;\n -text)\n- echo \"*.txt -text\" >.gitattributes\n+ echo \"* eol=crlf\" >.gitattributes\n+ echo \"*.txt -text\" >>.gitattributes\n ;;\n crlf)\n echo \"*.txt eol=crlf\" >.gitattributes\n"},{"id":"257182","messageId":"54F9E907.4040703@alum.mit.edu","threadId":"38711","inReplyTo":"54F9422D.2020800@web.de","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2015-03-06T17:51:03Z","receivedAt":"2015-03-06T17:51:03Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/06/2015 06:59 AM, Torsten Bögershausen wrote:\n> On 03/05/2015 11:08 PM, Junio C Hamano wrote:\n>> Michael Haggerty writes:\n>>\n>>> I would expect that the following .gitattributes file\n>>>\n>>> * eol=crlf\n>>> *.png -text\n>>>\n>>> would leave EOL translation turned off for PNG files. In other words, I\n>>> would expect that explicitly setting \"-text\" would take precedence over\n>>> the fact that setting \"eol\" implies that a file should be considered to\n>>> be \"text\".\n>>>\n>>> I would even more strongly expect\n>>>\n>>> * eol=crlf\n>>> *.png binary\n>>>\n>>> to turn off EOL translation for PNG files.\n>>>\n>>> But in fact, in both of the above cases, EOL translation is turned *on*\n>>> for PNG files.\n>>>\n>>> I propose that \"-text\" should override any setting for \"eol\" (which\n>>> would of course fix both problems, since \"binary\" is equivalent to\n>>> \"-diff -merge -text\"). What do people think?\n>> Hmm, is there really something that needs a new proposal and\n>> opinions?\n>>\n>> The way I read the flow in convert.c is:\n>>\n>> convert_to_git() uses input_crlf_action() to figure out what\n>> crlf_to_git() conversion is necessary.\n>>\n>> input_crlf_action() looks at text_attr and says CRLF_BINARY when\n>> it is CRLF_BINARY without looking at eol_attr at all.\n>>\n>> text_attr above is ca.crlf_action in convert_to_git().\n>>\n>> The whole ca.* comes from convert_attrs() inspecting attributes\n>> on the incoming path.\n>>\n>> convert_attrs() inspects \"eol\" and \"text\" attributes, among\n>> others, and sets crlf_action by calling git_path_check_crlf().\n>>\n>> git_path_check_crlf() looks at the 'text' attribute; if it is\n>> set to false, it returns CRLF_BINARY.\n>>\n>> crlf_to_git() when given crlf_action==CRLF_BINARY is a no-op.\n>>\n>> So, with the above attributes where anything is eol=crlf by default\n>> and in addition *.png is binary (which contains -text), we shouldn't\n>> get any crlf munging. Am I reading/following the code incorrectly?\n>>\n>> Puzzled....\n>> -- \n> \n> I need to admit that I can't reproduce it here,\n> the following should trigger it, but all test cases pass\n> \n> \n> diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh\n> \n> index 452320d..22f031d 100755\n> --- a/t/t0027-auto-crlf.sh\n> +++ b/t/t0027-auto-crlf.sh\n> @@ -37,7 +37,8 @@ create_gitattributes () {\n> echo \"*.txt text\" >.gitattributes\n> ;;\n> -text)\n> - echo \"*.txt -text\" >.gitattributes\n> + echo \"* eol=crlf\" >.gitattributes\n> + echo \"*.txt -text\" >>.gitattributes\n> ;;\n> crlf)\n> echo \"*.txt eol=crlf\" >.gitattributes\n> \n\nOops, I misunderstood an internal bug report. In seems that it is the\nfollowing scenario that is incorrect:\n\n *.png text=auto eol=crlf\n\nwhen applied to a binary file.\n\nI'm currently studying documentation and writing tests to figure out the\nexact current behavior. But honestly, this end-of-line conversion stuff\nis bewildering, so it might take a while.\n\nSorry for the half-cocked bug report. I'll report back when I know more.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\n"},{"id":"257200","messageId":"54FA1C7B.3040906@web.de","threadId":"38711","inReplyTo":"54F9E907.4040703@alum.mit.edu","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-03-06T21:30:35Z","receivedAt":"2015-03-06T21:30:35Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"\n> Oops, I misunderstood an internal bug report. In seems that it is the\n> following scenario that is incorrect:\n>\n> *.png text=auto eol=crlf\nHm, I don't know if we support this combination at all.\n\nThe current logic supports auto-detection of text/binary,\n* text=auto\n(the files will get the line ending from core.eol or core.autocrlf)\n\nor the the setting of a line ending:\n*.sh eol=lf\n*.bat eol=crlf\n\n\nIs there a special use-case, which needs the combination of both ?\n"},{"id":"257490","messageId":"54FF450F.7040506@alum.mit.edu","threadId":"38711","inReplyTo":"54FA1C7B.3040906@web.de","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2015-03-10T19:25:03Z","receivedAt":"2015-03-10T19:25:03Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/06/2015 10:30 PM, Torsten Bögershausen wrote:\n> \n>> Oops, I misunderstood an internal bug report. In seems that it is the\n>> following scenario that is incorrect:\n>>\n>> *.png text=auto eol=crlf\n> Hm, I don't know if we support this combination at all.\n\nThe user can specify this combination in a .gitattributes file and we\nhave to react to it *some way*. Theoretically we could document that\nthis combination is undefined and/or emit an error if we see this\ncombination, but we don't do so.\n\n> The current logic supports auto-detection of text/binary,\n> * text=auto\n> (the files will get the line ending from core.eol or core.autocrlf)\n> \n> or the the setting of a line ending:\n> *.sh eol=lf\n> *.bat eol=crlf\n> \n> \n> Is there a special use-case, which needs the combination of both ?\n\nI'm still trying to infer the spirit of the current behavior, so caveats\nhere.\n\nThis comes from a real-life scenario where a user, somewhere early in\n.gitattributes, had\n\n * text\n * eol=crlf\n\nand then later (this could be in a subdirectory) tried to carve out\nexceptions to this rule by using\n\n *.png binary\n * text=auto\n\nIntuitively it *feels* like either of the later lines should suppress\nEOL translation in PNG files (assuming the PNG file has a NUL byte in\nthe first 8k, which this one did).\n\nIt seems to me that setting \"text=auto\" should mean that Git uses its\nheuristic to guess whether a particular file is text or not, and then\ntreats the file as if it had \"text\" or \"-text\" set. If the latter, then\nEOL translation should be suppressed.\n\nIt also seems to me that \"binary\" should imply \"-eol\".\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\n"},{"id":"257493","messageId":"xmqq385c1v13.fsf@gitster.dls.corp.google.com","threadId":"38711","inReplyTo":"54FF450F.7040506@alum.mit.edu","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-10T20:01:44Z","receivedAt":"2015-03-10T20:01:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> On 03/06/2015 10:30 PM, Torsten Bögershausen wrote:\n>> \n>>> Oops, I misunderstood an internal bug report. In seems that it is the\n>>> following scenario that is incorrect:\n>>>\n>>> *.png text=auto eol=crlf\n>> Hm, I don't know if we support this combination at all.\n>\n> The user can specify this combination in a .gitattributes file and we\n> have to react to it *some way*.\n>\n> Theoretically we could document that\n> this combination is undefined and/or emit an error if we see this\n> combination, but we don't do so.\n>\n>> The current logic supports auto-detection of text/binary,\n>> * text=auto\n>> (the files will get the line ending from core.eol or core.autocrlf)\n>> \n>> or the the setting of a line ending:\n>> *.sh eol=lf\n>> *.bat eol=crlf\n>> \n>> \n>> Is there a special use-case, which needs the combination of both ?\n>\n> I'm still trying to infer the spirit of the current behavior, so caveats\n> here.\n>\n> This comes from a real-life scenario where a user, somewhere early in\n> .gitattributes, had\n>\n> * text\n> * eol=crlf\n>\n> and then later (this could be in a subdirectory) tried to carve out\n> exceptions to this rule by using\n>\n> *.png binary\n> * text=auto\n>\n> Intuitively it *feels* like either of the later lines should suppress\n> EOL translation in PNG files (assuming the PNG file has a NUL byte in\n> the first 8k, which this one did).\n\nThe way I read the description of \"eol\" was that that was a more\nspecific way to do what used to be done with \"text\" (meaning \"OK,\nthat may be a text file, but how exactly is the end-of-line\nhandled?\"), so I would say if the above behaved the same way as\n\n *.png eol=crlf text\n\nthat would be the least surprising to me. But perhaps that is only\nbecause I know which one came first and which one came later for\nwhat purpose.\n\nBut ...\n\n> It seems to me that setting \"text=auto\" should mean that Git uses its\n> heuristic to guess whether a particular file is text or not, and then\n> treats the file as if it had \"text\" or \"-text\" set. If the latter, then\n> EOL translation should be suppressed.\n\n... I think this makes even more sense. I do not think the code is\nset up to do so. To be honest, eol_attr thing introduced in\nfd6cce9e (Add per-repository eol normalization, 2010-05-19) always\nconfuses me whenever I follow this codepath.\n\n> It also seems to me that \"binary\" should imply \"-eol\".\n\nI thought that \"eol\" attribute is not even looked at when you say\n\"binary\"; that is what I recall finding out when I dug into this\nearlier in the thread.\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/264850/focus=264872\n"},{"id":"257495","messageId":"54FF5376.7070500@web.de","threadId":"38711","inReplyTo":"54FF450F.7040506@alum.mit.edu","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-03-10T20:26:30Z","receivedAt":"2015-03-10T20:26:30Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 10.03.15 20:25, Michael Haggerty wrote:\n> On 03/06/2015 10:30 PM, Torsten Bögershausen wrote:\n>>\n>>> Oops, I misunderstood an internal bug report. In seems that it is the\n>>> following scenario that is incorrect:\n>>>\n>>> *.png text=auto eol=crlf\n>> Hm, I don't know if we support this combination at all.\n> \n> The user can specify this combination in a .gitattributes file and we\n> have to react to it *some way*. Theoretically we could document that\n> this combination is undefined and/or emit an error if we see this\n> combination, but we don't do so.\n> \n>> The current logic supports auto-detection of text/binary,\n>> * text=auto\n>> (the files will get the line ending from core.eol or core.autocrlf)\n>>\n>> or the the setting of a line ending:\n>> *.sh eol=lf\n>> *.bat eol=crlf\n>>\n>>\n>> Is there a special use-case, which needs the combination of both ?\n> \n> I'm still trying to infer the spirit of the current behavior, so caveats\n> here.\n> \n> This comes from a real-life scenario where a user, somewhere early in\n> .gitattributes, had\n> \n> * text\n> * eol=crlf\n> \n> and then later (this could be in a subdirectory) tried to carve out\n> exceptions to this rule by using\n> \n> *.png binary\n> * text=auto\nHm,\nI can see 2 problems here:\nthe \"binary\" attribute does not exist at all.\n\nI sometimes which we had it, but we don't.\nThere is \"text\" and \"-text\", and that is it.\n\nThe other problem is the order of the lines, which is fully\nintuitive for each person who has ever written a \"matching parser\".\n\nThe parser matches each file namr on it's own, depending on the matching:\n\n*.png -text\n* text=auto\nmeans that all png files are binary, and ALL files are \"auto\".\n\nGuess what happens to the png's ?\n\nThe second rule wins, as it is the last rule processed.\n\ngit check-attr text *\nA.png: text: auto\nB.txt: text: auto\n---\nIf we reverse the order in .gitattributes, things look better:\n* text=auto\n*.png -text\n\ngit check-attr text *\nA.png: text: unset\nB.txt: text: auto\n\n\n--------------------\nThis is not very intuitive or even surprising, at least for many people.\n\nUnless I mis-understand the problem, it may be that the documentation may be updated ?\n\nThe general rule for writing .gitattributes \nis to specify the \"wider\" rules first, and then the more specific rules after that.\n\nIt could be that \nDocumentation/gitattributes.txt\nshould mention this instead:\n------------------------\n*\t\t-text\n*.txt\t\ttext\n*.vcproj\teol=crlf\n*.sh\t\teol=lf\n------------------------\n\n\nThe other thing is to promote/mention the command \n\"git check-attr text *\"\n\nat a prominent place.\n\n> Intuitively it *feels* like either of the later lines should suppress\n> EOL translation in PNG files (assuming the PNG file has a NUL byte in\n> the first 8k, which this one did).\n> \n> It seems to me that setting \"text=auto\" should mean that Git uses its\n> heuristic to guess whether a particular file is text or not, and then\n> treats the file as if it had \"text\" or \"-text\" set. If the latter, then\n> EOL translation should be suppressed.\n> \n> It also seems to me that \"binary\" should imply \"-eol\".\n> \n> Michael\n> \n"},{"id":"257504","messageId":"54FF6D23.4060301@alum.mit.edu","threadId":"38711","inReplyTo":"xmqq385c1v13.fsf@gitster.dls.corp.google.com","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2015-03-10T22:16:03Z","receivedAt":"2015-03-10T22:16:03Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/10/2015 09:01 PM, Junio C Hamano wrote:\n> Michael Haggerty writes:\n>> [...]\n>> It seems to me that setting \"text=auto\" should mean that Git uses its\n>> heuristic to guess whether a particular file is text or not, and then\n>> treats the file as if it had \"text\" or \"-text\" set. If the latter, then\n>> EOL translation should be suppressed.\n> \n> ... I think this makes even more sense. I do not think the code is\n> set up to do so. To be honest, eol_attr thing introduced in\n> fd6cce9e (Add per-repository eol normalization, 2010-05-19) always\n> confuses me whenever I follow this codepath.\n\nWould this change be \"backwards-compatible enough\" that it can be made\nwithout waiting for Git 3.0?\n\n>> It also seems to me that \"binary\" should imply \"-eol\".\n> \n> I thought that \"eol\" attribute is not even looked at when you say\n> \"binary\"; that is what I recall finding out when I dug into this\n> earlier in the thread.\n\nWell, that's true, but the \"eol\" attribute can regain its effect if\n\"binary\" is followed by \"text\" or \"text=auto\". So I guess the simplest\nquestion is as follows. Suppose I have the following .gitattributes:\n\n a.foo eol=crlf\n a.foo binary\n a.foo text\n\nIt is obvious in this case that a.foo should be treated as a text file.\nShould it be processed with \"eol=crlf\", or should the intervening\n\"binary\" imply \"-eol\"?\n\nI guess it would be more natural to process it with \"eol=crlf\". So I\nwithdraw my proposal that \"binary\" should imply \"-eol\", provided the\nfirst change (that \"text=auto\" is treated the same as \"-text\" for binary\nfiles) is implemented.\n\nSo I guess the proposed new behavior WRT these attributes is:\n\n* \"text\" determines whether a file should be subject to EOL\n translation.\n* \"text=auto\" has the same effect as \"text\" or \"-text\", depending\n on the outcome of the binary detection heuristic; in particular,\n it causes EOL translation to be suppressed for files determined\n to be binary.\n* \"eol\" determines what EOLs should be translated to *if* the\n file is determined to be a text file.\n* If \"text\" is unspecified but \"eol\" is specified, then do EOL\n translation without a heuristic check.\n\nBut I still have to work out how core.autocrlf and the \"crlf\" attribute\nfit into all this.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\n"},{"id":"257505","messageId":"54FF6F1B.2030900@alum.mit.edu","threadId":"38711","inReplyTo":"54FF5376.7070500@web.de","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2015-03-10T22:24:27Z","receivedAt":"2015-03-10T22:24:27Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/10/2015 09:26 PM, Torsten Bögershausen wrote:\n> On 10.03.15 20:25, Michael Haggerty wrote:\n>> [...]\n>> I'm still trying to infer the spirit of the current behavior, so caveats\n>> here.\n>>\n>> This comes from a real-life scenario where a user, somewhere early in\n>> .gitattributes, had\n>>\n>> * text\n>> * eol=crlf\n>>\n>> and then later (this could be in a subdirectory) tried to carve out\n>> exceptions to this rule by using\n>>\n>> *.png binary\n>> * text=auto\n> Hm,\n> I can see 2 problems here:\n> the \"binary\" attribute does not exist at all.\n>\n> I sometimes which we had it, but we don't.\n> There is \"text\" and \"-text\", and that is it.\n\nThere is a \"binary\" macro that is equivalent to \"-diff -merge -text\". It\nis documented in gitattributes(5) under \"USING MACRO ATTRIBUTES\" and\n\"DEFINING MACRO ATTRIBUTES\".\n\n> The other problem is the order of the lines, which is fully\n> intuitive for each person who has ever written a \"matching parser\".\n> \n> The parser matches each file namr on it's own, depending on the matching:\n> \n> *.png -text\n> * text=auto\n> means that all png files are binary, and ALL files are \"auto\".\n> \n> Guess what happens to the png's ?\n> \n> The second rule wins, as it is the last rule processed.\n> \n> git check-attr text *\n> A.png: text: auto\n> B.txt: text: auto\n\nThat much is perfectly clear. The question is, what should happen when\nthe contents-based heuristic, whose use was requested by \"text=auto\",\ndetermines that A.png is in fact a binary file? Should it be subjected\nto EOL translation anyway? I think not.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\n"},{"id":"257510","messageId":"xmqqsidcxy2q.fsf@gitster.dls.corp.google.com","threadId":"38711","inReplyTo":"54FF6D23.4060301@alum.mit.edu","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-10T22:54:53Z","receivedAt":"2015-03-10T22:54:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> Well, that's true, but the \"eol\" attribute can regain its effect if\n> \"binary\" is followed by \"text\" or \"text=auto\". So I guess the simplest\n> question is as follows. Suppose I have the following .gitattributes:\n>\n> a.foo eol=crlf\n> a.foo binary\n> a.foo text\n>\n> It is obvious in this case that a.foo should be treated as a text file.\n> Should it be processed with \"eol=crlf\", or should the intervening\n> \"binary\" imply \"-eol\"?\n\nI would say former. You find out what attributes apply to a path\nand then consider the collective effect of these attributes that\nsurvived.\n\nSo the second \"No it is not text\" which is overruled by the \"oops,\nno that is text\" later should not get in the picture, I would say.\n\nAs binary is not just -text and turns other things off, those other\nthings will be off after these three.\n"},{"id":"257535","messageId":"54FFD89A.9050306@web.de","threadId":"38711","inReplyTo":"xmqqsidcxy2q.fsf@gitster.dls.corp.google.com","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2015-03-11T05:54:34Z","receivedAt":"2015-03-11T05:54:34Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 03/10/2015 11:54 PM, Junio C Hamano wrote:\n> Michael Haggerty writes:\n>\n>> Well, that's true, but the \"eol\" attribute can regain its effect if\n>> \"binary\" is followed by \"text\" or \"text=auto\". So I guess the simplest\n>> question is as follows. Suppose I have the following .gitattributes:\n>>\n>> a.foo eol=crlf\n>> a.foo binary\n>> a.foo text\n>>\n>> It is obvious in this case that a.foo should be treated as a text file.\n>> Should it be processed with \"eol=crlf\", or should the intervening\n>> \"binary\" imply \"-eol\"?\n> I would say former. You find out what attributes apply to a path\n> and then consider the collective effect of these attributes that\n> survived.\n>\n> So the second \"No it is not text\" which is overruled by the \"oops,\n> no that is text\" later should not get in the picture, I would say.\n>\n> As binary is not just -text and turns other things off, those other\n> things will be off after these three.\nNot sure if I follow:\nWhenever you specify -text, the eol doesn't matter, or what do I miss ?\n\nSpecifying \"*.txt eol=crlf\" includes \"*.txt text\",\nbut with the following it should be possible to turn on \"text=auto\"\n\ncat .gitattributes\n* eol=crlf\n*.sh eol=lf\n* text=auto\n*.png -text\n"},{"id":"257561","messageId":"xmqqwq2n5s9t.fsf@gitster.dls.corp.google.com","threadId":"38711","inReplyTo":"54FFD89A.9050306@web.de","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-11T17:59:58Z","receivedAt":"2015-03-11T17:59:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n> On 03/10/2015 11:54 PM, Junio C Hamano wrote:\n>> Michael Haggerty writes:\n>>\n>>> Well, that's true, but the \"eol\" attribute can regain its effect if\n>>> \"binary\" is followed by \"text\" or \"text=auto\". So I guess the simplest\n>>> question is as follows. Suppose I have the following .gitattributes:\n>>>\n>>> a.foo eol=crlf\n>>> a.foo binary\n>>> a.foo text\n>>>\n>> As binary is not just -text and turns other things off, those other\n>> things will be off after these three.\n> Not sure if I follow:\n> Whenever you specify -text, the eol doesn't matter, or what do I miss ?\n\nSomething unrelated to the main theme of this topic ;-).\n\nI was just saying that saying \"a.foo text\" is not a way to take your\nearlier mistake of saying \"a.foo binary\" back, if that \"binary\" was\nplaced on the path by mistake or an over-eager globbing. The 'text'\nattribute will be reset, but -diff you placed on the path by saying\n\"binary\" is still there after these three attribute lines and running\n\"git diff a.foo\" would sill show the effect from it.\n"},{"id":"257566","messageId":"5500A5F7.1000503@kdbg.org","threadId":"38711","inReplyTo":"xmqqsidcxy2q.fsf@gitster.dls.corp.google.com","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2015-03-11T20:30:47Z","receivedAt":"2015-03-11T20:30:47Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 10.03.2015 um 23:54 schrieb Junio C Hamano:\n> Michael Haggerty writes:\n>\n>> Well, that's true, but the \"eol\" attribute can regain its effect if\n>> \"binary\" is followed by \"text\" or \"text=auto\". So I guess the simplest\n>> question is as follows. Suppose I have the following .gitattributes:\n>>\n>> a.foo eol=crlf\n>> a.foo binary\n>> a.foo text\n>>\n>> It is obvious in this case that a.foo should be treated as a text file.\n>> Should it be processed with \"eol=crlf\", or should the intervening\n>> \"binary\" imply \"-eol\"?\n>\n> I would say former. You find out what attributes apply to a path\n> and then consider the collective effect of these attributes that\n> survived.\n>\n> So the second \"No it is not text\" which is overruled by the \"oops,\n> no that is text\" later should not get in the picture, I would say.\n>\n> As binary is not just -text and turns other things off, those other\n> things will be off after these three.\n\nIs that how attribute lookup works? I.e., given a path, all attributes \nare collected?\n\nIsn't it more like: Here we are interested in the \"eol\" attribute of \nthis file named \"a.foo\". And the lookup would find the first line that \nsays \"eol=crlf\". Elsewhere, we are interested in the \"binary\" attribute \nof the file named \"a.foo\", and lookup would find the second line that \nsets the \"binary\" attribute. And again elsewhere, we ask for the \"text\" \nattribute, and we find the last line that sets the \"text\" property.\n\nAm I totally off track?\n\n-- Hannes\n"},{"id":"257571","messageId":"xmqq7fun5ih6.fsf@gitster.dls.corp.google.com","threadId":"38711","inReplyTo":"5500A5F7.1000503@kdbg.org","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-11T21:31:33Z","receivedAt":"2015-03-11T21:31:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n>> I would say former. You find out what attributes apply to a path\n>> and then consider the collective effect of these attributes that\n>> survived.\n>>\n>> So the second \"No it is not text\" which is overruled by the \"oops,\n>> no that is text\" later should not get in the picture, I would say.\n>>\n>> As binary is not just -text and turns other things off, those other\n>> things will be off after these three.\n>\n> Is that how attribute lookup works? I.e., given a path, all attributes\n> are collected?\n>\n> Isn't it more like: Here we are interested in the \"eol\" attribute of\n> this file named \"a.foo\". And the lookup would find the first line that\n> says \"eol=crlf\". Elsewhere, we are interested in the \"binary\"\n> attribute of the file named \"a.foo\", and lookup would find the second\n> line that sets the \"binary\" attribute. And again elsewhere, we ask for\n> the \"text\" attribute, and we find the last line that sets the \"text\"\n> property.\n>\n> Am I totally off track?\n\nIn the codepath in question, we say \"we are interested in text and\neol attributes\", grab the values (set/unset/set-to-value/unspecified)\nfor these two for the path we are interested in from all the\napplicable gitattributes file and then act on the result.\n"},{"id":"257572","messageId":"xmqq385b5hwu.fsf@gitster.dls.corp.google.com","threadId":"38711","inReplyTo":"xmqq7fun5ih6.fsf@gitster.dls.corp.google.com","subject":"Re: Surprising interaction of \"binary\" and \"eol\" gitattributes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-11T21:43:45Z","receivedAt":"2015-03-11T21:43:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Johannes Sixt writes:\n>\n>> Isn't it more like: Here we are interested in the \"eol\" attribute of\n>> this file named \"a.foo\". And the lookup would find the first line that\n>> says \"eol=crlf\". Elsewhere, we are interested in the \"binary\"\n>> attribute of the file named \"a.foo\", and lookup would find the second\n>> line that sets the \"binary\" attribute. And again elsewhere, we ask for\n>> the \"text\" attribute, and we find the last line that sets the \"text\"\n>> property.\n>>\n>> Am I totally off track?\n>\n> In the codepath in question, we say \"we are interested in text and\n> eol attributes\", grab the values (set/unset/set-to-value/unspecified)\n> for these two for the path we are interested in from all the\n> applicable gitattributes file and then act on the result.\n\nTechnically the above is only a half-answer; I know you are\nintelligent enough to derive the other untold half from it, but for\nthe benefit of those reading from sidelines....\n\nThe calling convention to (1) prepare the list of attributes you are\ninterested in upfront and then (2) to ask the set of attributes that\napply among that set for a path is designed to force programmers\navoid doing attribute lookups (which is rather expensive) at random\nplaces in their code. But in the end, this let us implement the\nfunctionality as you alluded to in the quote paragraph.\n\nIf a proposed change wants to make 'text=auto' stronger in the sense\nthat we decide if we pay attention to 'eol' only after checking if\nthe contents look non-text, it can do so, just like setting '-text'\nto the current code makes settings of 'eol' irrelevant.\n"}]}