{"thread":{"id":"23448","subject":"[PATCH] make description of \"core.autocrlf\" less ambiguous","startedAt":"2010-04-13T23:23:23Z","lastAt":"2010-04-14T14:49:34Z","messageCount":3,"participants":["Will Palmer","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"139439","messageId":"1271201003-3413-1-git-send-email-wmpalmer@gmail.com","threadId":"23448","inReplyTo":null,"subject":"[PATCH] make description of \"core.autocrlf\" less ambiguous","fromName":"Will Palmer","fromEmail":"wmpalmer@gmail.com","sentAt":"2010-04-13T23:23:23Z","receivedAt":"2010-04-13T23:23:23Z","isPatch":true,"sender":{"key":"wmpalmer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/357044?v=4"},"body":"The description for core.autocrlf refers to reads from / writes to the\n\"filesystem\". While the term is used elsewhere in the config\ndocumentation to refer to the filesystem git is hosted on, it is not\nonly less clear from context in the case of core.autocrlf, but can also\nbe plain inaccurate in many cases.\n\nTo make more clear the direction of removal / addition of CR when\ncore.crlf is set, as well as to account for the usage of low-level\ncommands such as hash-object or cat-file, we change \"reading from the\nfilesystem\" to refer instead to \"writing to the object database\", and\n\"writing to the filesystem\" to \"output or writing to the work tree\"\n\nSigned-off-by: Will Palmer \n---\n\nWhile I did some simple checks to ensure that my basic assumptions about\nhow the commands I use daily seem to interact with core.autocrlf, I'll\neasily admit that I don't actually know all the places autocrlf is\nreferenced, so I could be completely wrong about what generalizations\ncan actually be made in the documentation.\nI'm fine with this patch being included, but it's pretty much just me\n\"being bold\" in order to say that I think the way it's currently\nphrased is wrong and confusing.\n\n Documentation/config.txt | 10 +++++-----\n 1 files changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 626b19a..125e9d5 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -198,11 +198,11 @@ core.quotepath::\n \n core.autocrlf::\n \tIf true, makes git convert `CRLF` at the end of lines in text files to\n-\t`LF` when reading from the filesystem, and convert in reverse when\n-\twriting to the filesystem. The variable can be set to\n-\t'input', in which case the conversion happens only while\n-\treading from the filesystem but files are written out with\n-\t`LF` at the end of lines. A file is considered\n+\t`LF` when writing into the object database, and convert in reverse when\n+\toutputting those files or writing them to the work tree. The variable\n+\tcan be set to 'input', in which case the conversion happens only while\n+\twriting into the object database, but files are output and written to the\n+\twork tree with `LF` at the end of lines. A file is considered\n \t\"text\" (i.e. be subjected to the autocrlf mechanism) based on\n \tthe file's `crlf` attribute, or if `crlf` is unspecified,\n \tbased on the file's contents. See linkgit:gitattributes[5].\n-- \n1.7.1.rc1.248.gcefbb\n"},{"id":"139478","messageId":"7vk4saqguf.fsf@alter.siamese.dyndns.org","threadId":"23448","inReplyTo":"1271201003-3413-1-git-send-email-wmpalmer@gmail.com","subject":"Re: [PATCH] make description of \"core.autocrlf\" less ambiguous","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-14T13:55:04Z","receivedAt":"2010-04-14T13:55:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Will Palmer writes:\n\n> While I did some simple checks to ensure that my basic assumptions about\n> how the commands I use daily seem to interact with core.autocrlf, I'll\n> easily admit that I don't actually know all the places autocrlf is\n> referenced, so I could be completely wrong about what generalizations\n> can actually be made in the documentation.\n\nThanks.\n\nThe description uses \"reading from the filesystem\" vs \"writing to the\nfilesystem\" but as you may have noticed, there are cases that we do not\ninteract with \"the filesystem\". Reading (e.g. \"hash-object --stdin\") from\nthe standard input may read (e.g. \"hash-object --stdin wrote:\n> Very low level plumbing commands deliberately omit the conversion in order\n> to show the raw data (e.g. cat-file), so it is not correct to reword it to\n> \"when output\" as in your version.\n\nBlame poor testing on my part, then. Yesterday, my tests showed\n\"cat-file blob HEAD:a-crlf-file\" outputting crlf lines, but\ntoday (with a script, rather than my typing commands in by-hand) that\nseems not to be the case.\n\nI agree that verbose-and-anal is not the right way to go, but I still\nthink the phrases reading from / writing to \"the filesystem\"\nsound very ambiguous, especially when related to a command which\neffects the way git stores things in its internal filesystem.\n\nMost other uses of the term \"filesystem\" in the manpage use wording\nsuch as: \"...filesystems like NFS..\",\n \"..filesystems like FAT..\", \"traditional UNIX filesystems\", etc. The\nonly non-explicit uses of the term talk about\n\"slow filesystems\", which are clearly talking about something other\nthan git. The autocrlf mention is the only use of the\nterm \"the filesystem\".\n\nThough at the time I thought I wasn't being anal enough, perhaps the\ncorrect move would be to go the opposite direction:\ntechnically not the-real-truth, but \"good enough\": maybe both\nreferences to \"the filesystem\" should just be replaced with\n\"the work tree\", which is the term used in the safecrlf section anyway?\n"}]}