{"thread":{"id":"30106","subject":"Is the \"text\" attribute meant *only* to specify end-of-line normalization behavior, or does it have broader implications?","startedAt":"2012-03-30T02:19:26Z","lastAt":"2012-03-30T21:30:56Z","messageCount":6,"participants":["Chris Harris","Johannes Sixt","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"188117","messageId":"CANSc5vG0o_eAn7X39XhCzUoN4ab52pGCP+PvzOQCyTV31R8LGg@mail.gmail.com","threadId":"30106","inReplyTo":null,"subject":"Is the \"text\" attribute meant *only* to specify end-of-line normalization behavior, or does it have broader implications?","fromName":"Chris Harris","fromEmail":"ryguasu@gmail.com","sentAt":"2012-03-30T02:19:26Z","receivedAt":"2012-03-30T02:19:26Z","isPatch":false,"sender":{"key":"ryguasu@gmail.com","avatar":null},"body":"The gitattributes documentation (e.g. from \"git help attributes\")\ngives the impression that the \"text\" attribute's sole effect is to\ncontrol whether or not end-of-line normalization takes place. I wanted\nto check whether I'm indeed supposed to take such a narrow\ninterpretation as a git user, or whether setting \"text\" or \"-text\"\nmight have a broader meaning (or whether it will have a broader\nmeaning in the future).\n\nIn the rest of this message, let me outline a case of current interest\nwhere the distinction seems to matter:\n\nI'm starting a new repository for a Windows-only project where I don't\nthink I want git to do any end-of-line normalization on my text files.\n(I'm totally happy to have CRLFs both in the repo and in all the\nworking copies.) Unless you think that end-of-line normalization is\nalways vital, let's try to presume I've made the right choice about\nthis.\n\nNow as far I can tell from the gitattributes documentation, one\nperfectly legitimate way to accomplish this (and to override any\ncore.autocrlf settings on other teammates' machines in the process) is\nto add a .gitignore file to my repo containing the single line\n\n    * -text\n\nIf all \"-text\" does is disable end-of-line normalization, then this\nsetting should be a small deal. For example, it shouldn't\nfundamentally alter how any of the source control operations (diffs,\nmerges, etc.) work on my text files, or generate more merge conflicts\nthan otherwise. (Recall that I'm starting a fresh repo, so I don't\nhave to worry that the repo might already have some normalized\nlinefeeds.)\n\nBut I'm not completely sure if it's reasonable to expect there to be\nno side-effects. I haven't yet discovered any side-effects from git\nitself, but I have at least discovered one in the Git Extensions\nproject, which takes a broader interpretation of \"-text\". Some of you\nmight not care directly about Git Extensions, but perhaps you can\nstill help me figure out whether I'm making a misguided use of\n\"-text\", or whether this is perhaps an area where Git Extensions is\ndoing the wrong thing:\n\n* Here's the normal behavior (without \"* -text\"): Git Extensions has a\nwidget that lets you explore a given commit. In that widget, if you\nclick on the name of a text file, then the contents of that file shows\nup in an adjacent pane. In contrast, if you click on the name of a\nbinary file, then the adjacent pane simply says, e.g., \"Binary file:\nfoo.jpg\".\n* Here's the behavior with \"* -text\" in my .gitattributes: Now, no\nmatter what file I click on in the above widget, the pane says, e.g.,\n\"Binary file: foo.txt\". I can no longer see the contents of any text\nfiles, which is annoying.\n* I peeked at the Git Extensions code, and it is making the following\ninference: The path to foo.txt is tagged as \"-text\", therefore the\nfile is \"binary\", therefore it doesn't make sense to display its\ncontents to the user, and therefore I'll just display \"Binary file:\nfoo.txt\" instead. But this is an unfortunate consequence. When I\noriginally set \"-text\" I didn't mean to convey \"this is a binary\nfile\", merely \"don't mess with newlines.\"\n"},{"id":"188130","messageId":"4F7555BC.1000804@viscovery.net","threadId":"30106","inReplyTo":"CANSc5vG0o_eAn7X39XhCzUoN4ab52pGCP+PvzOQCyTV31R8LGg@mail.gmail.com","subject":"Re: Is the \"text\" attribute meant *only* to specify end-of-line normalization behavior, or does it have broader implications?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-03-30T06:42:04Z","receivedAt":"2012-03-30T06:42:04Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 3/30/2012 4:19, schrieb Chris Harris:\n> I'm starting a new repository for a Windows-only project where I don't\n> think I want git to do any end-of-line normalization on my text files.\n> (I'm totally happy to have CRLFs both in the repo and in all the\n> working copies.)\n\nThe question is rather: Are you happy if someone commits a file that does\n*not* have CRLF, but only LF?\n\nBecause if you don't care, you are better off setting no attributes and no\ncore.autocrlf and no core.eol at all. The git will take the file\nunmodified. If someone's editor changes the eol style of a file, it will\nbe noticed because the diff will show that the entire file has changed.\nYour team mates should better have enough discipline not to ignore such a\nhint that something's gone awry, of course.\n\n> Unless you think that end-of-line normalization is\n> always vital, let's try to presume I've made the right choice about\n> this.\n\nIt's your code, you are to judge what is best for you. IOW, I don't think\nthat eol normalization is \"always vital\", and you are right. :-)\n\n(I didn't answer the question in the subject of your message, and I can't;\nI don't use the text attribute nor eol normalization, even though I work\non Windows quite a lot.)\n\n-- Hannes\n"},{"id":"188134","messageId":"20120330072546.GC30656@sigill.intra.peff.net","threadId":"30106","inReplyTo":"4F7555BC.1000804@viscovery.net","subject":"Re: Is the \"text\" attribute meant *only* to specify end-of-line normalization behavior, or does it have broader implications?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-30T07:25:46Z","receivedAt":"2012-03-30T07:25:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 30, 2012 at 08:42:04AM +0200, Johannes Sixt wrote:\n\n> Am 3/30/2012 4:19, schrieb Chris Harris:\n> > I'm starting a new repository for a Windows-only project where I don't\n> > think I want git to do any end-of-line normalization on my text files.\n> > (I'm totally happy to have CRLFs both in the repo and in all the\n> > working copies.)\n> \n> The question is rather: Are you happy if someone commits a file that does\n> *not* have CRLF, but only LF?\n> \n> Because if you don't care, you are better off setting no attributes and no\n> core.autocrlf and no core.eol at all. The git will take the file\n> unmodified. If someone's editor changes the eol style of a file, it will\n> be noticed because the diff will show that the entire file has changed.\n> Your team mates should better have enough discipline not to ignore such a\n> hint that something's gone awry, of course.\n\nI think it may be slightly more complex than that. He may be OK with\n\"git does nothing\" and assuming everybody's editor does the sane thing.\nBut he may _not_ be OK with a stray core.autocrlf setting in a project\nmember's git config normalizing all line endings whenever they touch a\nfile. Setting \"-text\" prevents the latter.\n\n> (I didn't answer the question in the subject of your message, and I can't;\n> I don't use the text attribute nor eol normalization, even though I work\n> on Windows quite a lot.)\n\nI don't use them either.\n\nHowever, I find the behavior of \"Git Extensions\" to be questionable. I\ncan see the rationale for thinking that \"-text\" means more than just\nhandling line-endings, but I think \"-diff\" is probably a better choice\nfor seeing if something is binary (or even checking the \"binary\" macro).\nThose are what git uses itself.\n\nPerhaps it was a mistake to call it \"text\", as it invites this sort of\nconfusion.\n\n-Peff\n\nPS I think one could potentially work around the whole issue by setting\n   \"-crlf\", which git treats equivalently to \"-text\" these days (and\n   hopefully isn't also checked by Git Extensions).\n"},{"id":"188181","messageId":"CANSc5vGaodyv4H5qp2ZkjY7q6ot7_JG0jdvNDFRBFW1+p7v4sw@mail.gmail.com","threadId":"30106","inReplyTo":"20120330072546.GC30656@sigill.intra.peff.net","subject":"Re: Is the \"text\" attribute meant *only* to specify end-of-line normalization behavior, or does it have broader implications?","fromName":"Chris Harris","fromEmail":"ryguasu@gmail.com","sentAt":"2012-03-30T17:49:42Z","receivedAt":"2012-03-30T17:49:42Z","isPatch":false,"sender":{"key":"ryguasu@gmail.com","avatar":null},"body":"On Fri, Mar 30, 2012 at 12:25 AM, Jeff King <peff@peff.net> wrote:\n> On Fri, Mar 30, 2012 at 08:42:04AM +0200, Johannes Sixt wrote:\n>\n>> Am 3/30/2012 4:19, schrieb Chris Harris:\n>> > I'm starting a new repository for a Windows-only project where I don't\n>> > think I want git to do any end-of-line normalization on my text files.\n>> > (I'm totally happy to have CRLFs both in the repo and in all the\n>> > working copies.)\n>>\n>> The question is rather: Are you happy if someone commits a file that does\n>> *not* have CRLF, but only LF?\n>>\n>> Because if you don't care, you are better off setting no attributes and no\n>> core.autocrlf and no core.eol at all. The git will take the file\n>> unmodified. If someone's editor changes the eol style of a file, it will\n>> be noticed because the diff will show that the entire file has changed.\n>> Your team mates should better have enough discipline not to ignore such a\n>> hint that something's gone awry, of course.\n>\n> I think it may be slightly more complex than that. He may be OK with\n> \"git does nothing\" and assuming everybody's editor does the sane thing.\n> But he may _not_ be OK with a stray core.autocrlf setting in a project\n> member's git config normalizing all line endings whenever they touch a\n> file. Setting \"-text\" prevents the latter.\n\nYes, avoiding stray core.autocrlf settings was indeed one of my main\nmotivations. Johannes is right that ideally a teammate is going to\nnotice if all of us a sudden a whole file has changed. But I also\nbelieve that, if there's an easy way to prevent people from\naccidentally doing the wrong thing when they're tired/hurried/whatever\nand it has no bad side-effects, why not enable it?\n\nThe problem is slightly intensified for users of msysgit on Windows;\nthe msysgit installer guides one toward picking core.autocrlf=true as\nyour system default. Making sure that every last teammate disables\nautocrlf seems potentially error-prone.\n\n> However, I find the behavior of \"Git Extensions\" to be questionable. I\n> can see the rationale for thinking that \"-text\" means more than just\n> handling line-endings, but I think \"-diff\" is probably a better choice\n> for seeing if something is binary (or even checking the \"binary\" macro).\n> Those are what git uses itself.\n>\n> Perhaps it was a mistake to call it \"text\", as it invites this sort of\n> confusion.\n\nOk, thanks. That's helpful.\n\nA related point of confusion: I've noticed that, if you start with a\nquestion along the lines of \"how can I explicitly tell git that a file\nis binary\", then the web currently gives a slightly confusing array of\nanswers. For example:\n* The Pro Git Book (http://progit.org/book/ch7-2.html) tells you to\nuse either \"binary\" or \"-crlf -diff\"\n* http://www.bluishcoder.co.nz/2007/09/git-binary-files-and-cherry-picking.html\ntells you to use \"-crlf -diff -merge\"\n* http://www.dont-panic.cc/capi/2009/02/16/how-to-force-git-to-consider-a-file-as-binary/\ntells you to use \"-crlf\"\n* \"man gitattributes\" has helpful info, but it's scattered across\ndifferent sections. In the section \"Marking files as binary\", it says\n\"The simplest way to mark a file as binary is to unset the diff\nattribute in the .gitattributes file\". (Note: This implies that there\nare other ways you might also want to consider.) Under \"Performing a\nthree-way merge\" you also learn that \"-merge\" is \"suitable for binary\nfiles that do not have a well-defined merge semantics\". You learn\nabout the \"binary\" attribute only under the section \"Defining Macro\nAttributes\", which says that it means \"-text -diff\", but not in what\ncases you might want to use it. The section describing \"text\"/\"-text\"\ndoes not contain the word \"binary\" at all, so you have to infer\nwhether it's a helpful setting for binary files.\n\nIt makes me wonder if the documentation could be improved a little on\nthis count, though I don't yet feel solid enough in my understanding\nto propose a particular patch.\n\n> PS I think one could potentially work around the whole issue by setting\n>   \"-crlf\", which git treats equivalently to \"-text\" these days (and\n>   hopefully isn't also checked by Git Extensions).\n\nYes, that sounds like a plausible way to go.\n"},{"id":"188183","messageId":"7v62dmlzjl.fsf@alter.siamese.dyndns.org","threadId":"30106","inReplyTo":"CANSc5vGaodyv4H5qp2ZkjY7q6ot7_JG0jdvNDFRBFW1+p7v4sw@mail.gmail.com","subject":"Re: Is the \"text\" attribute meant *only* to specify end-of-line normalization behavior, or does it have broader implications?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-30T18:22:06Z","receivedAt":"2012-03-30T18:22:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Harris <ryguasu@gmail.com> writes:\n\n> A related point of confusion: I've noticed that, if you start with a\n> question along the lines of \"how can I explicitly tell git that a file\n> is binary\", then the web currently gives a slightly confusing array of\n> answers. For example:\n>...\n> It makes me wonder if the documentation could be improved a little on\n> this count, though I don't yet feel solid enough in my understanding\n> to propose a particular patch.\n\nIf you only read your analysis on gitattributes documentation, it would be\nclear that text/-text does not have much to do with binaryness, and it\nalso gives an authoritative advice \"binary\".\n\nWe do not have direct control over third-party sites that give incorrect\ninformation, so people need to bug them as they find mistakes.  I think\nProGit actively accepts patches; I do not know about others.\n\nThanks.\n"},{"id":"188210","messageId":"20120330213055.GC20734@sigill.intra.peff.net","threadId":"30106","inReplyTo":"CANSc5vGaodyv4H5qp2ZkjY7q6ot7_JG0jdvNDFRBFW1+p7v4sw@mail.gmail.com","subject":"Re: Is the \"text\" attribute meant *only* to specify end-of-line normalization behavior, or does it have broader implications?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-30T21:30:56Z","receivedAt":"2012-03-30T21:30:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 30, 2012 at 10:49:42AM -0700, Chris Harris wrote:\n\n> > However, I find the behavior of \"Git Extensions\" to be questionable. I\n> > can see the rationale for thinking that \"-text\" means more than just\n> > handling line-endings, but I think \"-diff\" is probably a better choice\n> > for seeing if something is binary (or even checking the \"binary\" macro).\n> > Those are what git uses itself.\n> [...]\n> A related point of confusion: I've noticed that, if you start with a\n> question along the lines of \"how can I explicitly tell git that a file\n> is binary\", then the web currently gives a slightly confusing array of\n> answers. For example:\n> * The Pro Git Book (http://progit.org/book/ch7-2.html) tells you to\n> use either \"binary\" or \"-crlf -diff\"\n\nI think setting \"binary\" is the most sane thing. Ultimately, I think\nwhat it comes down to is this: git provides a bunch of per-operation\nattributes for treating a file as binary for a particular operation. It\nalso provides a \"binary\" macro to conveniently cover all of the\noperations.\n\nGit Extensions cares about binary-ness for a _new_ operation, which is\nshowing the file at all (that is what I got from your original email, at\nleast; I have never used Git Extensions myself). The equivalent in git\nwould be perhaps for \"git show HEAD:file\" to either print a text file,\nor to say \"This is a binary file\". But since git itself does not care\nabout binary-ness for that operation (we just always show the file), we\nhave not defined an operation-specific attribute.\n\nSo what is something like Git Extensions to do? It can introduce a new\nattribute, but of course nobody is likely to be using it. It can depend\non \"binary\", except that some people will manually spell out \"-crlf\n-diff\" instead of saying \"binary\". Or it can piggy-back on \"-text\" or\n\"-diff\", which can be subtly wrong in cases where the file is not\nbinary, but you want to disable those operations (i.e., your case).\n\nOf those, just checking \"binary\" seems like the least wrong thing to me.\n\n> * \"man gitattributes\" has helpful info, but it's scattered across\n> different sections. In the section \"Marking files as binary\", it says\n> \"The simplest way to mark a file as binary is to unset the diff\n> attribute in the .gitattributes file\".\n\nNote that \"Marking files as binary\" is actually a subsection in\n\"Generating diff text\". We could probably do a better job of mentioning\nthe \"binary\" macro there, though.\n\n> (Note: This implies that there > are other ways you might also want to\n> consider.)\n\nYes. You can also use a custom diff driver (e.g., \"diff=foo\"), and then\ntell the diff driver that the file should be considered binary (by\nsetting diff.foo.binary in your config).\n\n> Under \"Performing a three-way merge\" you also learn that \"-merge\" is\n> \"suitable for binary files that do not have a well-defined merge\n> semantics\".\n\nArguably the \"binary\" macro should imply \"-merge\". And like -diff, we\nthe documentation should probably reference the section on the \"binary\"\nmacro.\n\n> You learn about the \"binary\" attribute only under the section\n> \"Defining Macro Attributes\", which says that it means \"-text -diff\",\n> but not in what cases you might want to use it. The section describing\n> \"text\"/\"-text\" does not contain the word \"binary\" at all, so you have\n> to infer whether it's a helpful setting for binary files.\n\nI think it is the case that binary files should imply \"-text\", but\n\"-text\" does not necessarily imply binary files. But like the other\nspots, it should probably say \"hey, if you are dealing with a binary\nfile, you might want to just set the binary attribute macro\".\n\n-Peff\n"}]}