{"thread":{"id":"24588","subject":"noob user, want checkins to all be forced to LF terminated lines","startedAt":"2010-07-31T04:23:43Z","lastAt":"2010-08-04T05:29:35Z","messageCount":16,"participants":["Walter Bright","Jonathan Nieder","Ilari Liusvaara","Miles Bader","David Aguilar","Jay Soffian","Will Palmer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"146834","messageId":"i308gl$v6p$1@dough.gmane.org","threadId":"24588","inReplyTo":null,"subject":"noob user, want checkins to all be forced to LF terminated lines","fromName":"Walter Bright","fromEmail":"boost@digitalmars.com","sentAt":"2010-07-31T04:23:43Z","receivedAt":"2010-07-31T04:23:43Z","isPatch":false,"sender":{"key":"boost@digitalmars.com","avatar":null},"body":"I've just started with git. Exactly what do I put in $HOME/.gitconfig ?\n\nI find the text at \nhttp://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_checking_out_and_checking_in\n\nto be confusing. Which of the text, eol, crlf, or autocrlf attributes do I set, \nand exactly what text do I put in the config file?\n\nThanks for any help!\n"},{"id":"146836","messageId":"20100731044957.GA8920@burratino","threadId":"24588","inReplyTo":"i308gl$v6p$1@dough.gmane.org","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-31T04:49:57Z","receivedAt":"2010-07-31T04:49:57Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Walter Bright wrote:\n\n> I've just started with git.\n\nI thought I saw you here years ago. :)\n\n> Exactly what do I put in $HOME/.gitconfig ?\n\nWell, naturally it depends on what you want to happen.\n\nIf you just want to make sure any new files you commit are tracked\nwith simple LF line endings, you can use\n\n\t[core]\n\t\tautocrlf = input\n\nWith this setting, Git will not do any munging to files in the work\ntree in any way (unless there is a .gitattributes file requesting to\ndo so).\n\nThat is an _altruistic_ setting to use.  It ensures you do not pollute\nhistory with some alternative line-ending, but your own work tree may\nnot necessarily match the cleaned up versions you are checking in; so\nif you try to \"git add\" and then \"touch\" a file with CRLF line endings\nwith this setting enabled, you may be surprised at the result!\n(Though a simple \"git checkout file.c\" afterwards should fix up the\nline endings in the work tree.)\n\nIf you want to make sure text files in the work tree use LF line\nendings and you are using a recent version of Git, use the above\nsetting or\n\n\t[core]\n\t\teol = lf\n\nOn Unix-y systems, you do not have to do that, since it is the\ndefault.  On Windows, the \"[core] autocrlf\" setting is set up\nby default in /etc/gitconfig so you would probably want to\noverride that with\n\n\t[core]\n\t\tautocrlf = false\n\nif you are not setting it to input.\n\nWhich files are text files? you may ask.  By default (unless\nautocrlf is enabled), Git treats files as raw data; to get it\nto futz with line endings, you have to declare your text files\nin a file named .gitattributes in the tracked tree.\n\n\t* crlf\n\t*.jpg -crlf\n\t*.png -crlf\n\nThe keyword crlf here means “apply line-ending conversions” and\nnothing more.  In particular, it does not represent the preferred\nline ending.\n\nIf everyone for which you want these setting to take effect uses a\nrecent version of git, you can write “text” instead of “crlf” if\nyou prefer.\n\nHope that helps,\nJonathan\n"},{"id":"146837","messageId":"i30bg7$50k$1@dough.gmane.org","threadId":"24588","inReplyTo":"20100731044957.GA8920@burratino","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Walter Bright","fromEmail":"boost@digitalmars.com","sentAt":"2010-07-31T05:14:40Z","receivedAt":"2010-07-31T05:14:40Z","isPatch":false,"sender":{"key":"boost@digitalmars.com","avatar":null},"body":"Jonathan Nieder wrote:\n> Walter Bright wrote:\n> \n>> I've just started with git.\n> \n> I thought I saw you here years ago. :)\n\nI've been around, just not in git.\n\n\n>> Exactly what do I put in $HOME/.gitconfig ?\n> \n> Well, naturally it depends on what you want to happen.\n> \n> If you just want to make sure any new files you commit are tracked\n> with simple LF line endings, you can use\n> \n> \t[core]\n> \t\tautocrlf = input\n> \n> With this setting, Git will not do any munging to files in the work\n> tree in any way (unless there is a .gitattributes file requesting to\n> do so).\n\ngit is installed under Ubuntu, but I'll be checking in files that I edit on both \nWindows and Ubuntu, so the line endings will vary depending on which platform I \nlast editted the file on. Hence, I want to force them all to be LF upon checkin.\n\n> That is an _altruistic_ setting to use.  It ensures you do not pollute\n> history with some alternative line-ending, but your own work tree may\n> not necessarily match the cleaned up versions you are checking in; so\n> if you try to \"git add\" and then \"touch\" a file with CRLF line endings\n> with this setting enabled, you may be surprised at the result!\n> (Though a simple \"git checkout file.c\" afterwards should fix up the\n> line endings in the work tree.)\n\n\n> If you want to make sure text files in the work tree use LF line\n> endings and you are using a recent version of Git, use the above\n> setting or\n> \n> \t[core]\n> \t\teol = lf\n\nSo this changes the file in the repository to lf only, but not in the worktree? \nThat's what I want.\n\n> On Unix-y systems, you do not have to do that, since it is the\n> default.  On Windows, the \"[core] autocrlf\" setting is set up\n> by default in /etc/gitconfig so you would probably want to\n> override that with\n> \n> \t[core]\n> \t\tautocrlf = false\n> \n> if you are not setting it to input.\n> \n> Which files are text files? you may ask.  By default (unless\n> autocrlf is enabled), Git treats files as raw data; to get it\n> to futz with line endings, you have to declare your text files\n> in a file named .gitattributes in the tracked tree.\n> \n> \t* crlf\n> \t*.jpg -crlf\n> \t*.png -crlf\n\nIn the tracked tree? The documentation:\n\nhttp://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_checking_out_and_checking_in\n\nsays it goes in:\n\n  $GIT_DIR/info/attributes, .gitattributes\n\nso I'm confused again. Does .gitattributes go in $GIT_DIR, or in $GIT_DIR/info ? \nAnd what if both of those files are there, which one 'wins' ?\n\n\n\n> The keyword crlf here means “apply line-ending conversions” and\n> nothing more.  In particular, it does not represent the preferred\n> line ending.\n> \n> If everyone for which you want these setting to take effect uses a\n> recent version of git, you can write “text” instead of “crlf” if\n> you prefer.\n\ngit --version says I'm using 1.5.6.3\n\n> Hope that helps,\n\nYes, it does, thank you!\n\nA final question: where does the repository actually go (so I can back it up)? \nThis is a local thing, I'm not trying to set up a networked or remote \nrepository, so it'll be the default location.\n"},{"id":"146838","messageId":"20100731053918.GA19688@LK-Perkele-V2.elisa-laajakaista.fi","threadId":"24588","inReplyTo":"i30bg7$50k$1@dough.gmane.org","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2010-07-31T05:39:18Z","receivedAt":"2010-07-31T05:39:18Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Fri, Jul 30, 2010 at 10:14:40PM -0700, Walter Bright wrote:\n> \n> A final question: where does the repository actually go (so I can\n> back it up)? This is a local thing, I'm not trying to set up a\n> networked or remote repository, so it'll be the default location.\n\n.git directory in root of working copy. One way to backup is just\nto do recursive backup of entiere working copy[1].\n\n[1] But upon restore, the working copy cache will be wrong and\nneeds to be rebuilt (git update-index --refresh).\n\n-Ilari\n"},{"id":"146839","messageId":"87zkx8cinf.fsf@catnip.gol.com","threadId":"24588","inReplyTo":"i308gl$v6p$1@dough.gmane.org","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-07-31T05:41:40Z","receivedAt":"2010-07-31T05:41:40Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Walter Bright <boost@digitalmars.com> writes:\n> I've just started with git. Exactly what do I put in $HOME/.gitconfig ?\n\n+ your personal info (user.*)\n\n+ various global personal preferences for tool operation\n  (diff.renames, branch.autosetupmerge, apply.whitespace)\n\n+ core.excludesfile = ~/.gitignore\n\n  ... then in ~/.gitignore, put filenames to ignore that are related to\n  your personal habits or tool preferences rather than any particular\n  project (e.g., \"*~\" if you use emacs; I also put \",*\" because I use\n  that pattern for scratch files)\n\n+ command aliases (alias.*)\n\n-miles\n\n-- \nA zen-buddhist walked into a pizza shop and\nsaid, \"Make me one with everything.\"\n"},{"id":"146840","messageId":"20100731054437.GD14425@burratino","threadId":"24588","inReplyTo":"i30bg7$50k$1@dough.gmane.org","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-31T05:44:37Z","receivedAt":"2010-07-31T05:44:37Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi again,\n\nSome clarifications.\n\nWalter Bright wrote:\n\n> git is installed under Ubuntu, but I'll be checking in files that I\n> edit on both Windows and Ubuntu, so the line endings will vary\n> depending on which platform I last editted the file on. Hence, I\n> want to force them all to be LF upon checkin.\n\n\"[core] autocrlf = input\" would work.  With this setting, the work\ntree is considered sacred (i.e., not touched in any magical way at\nall) but content checked in that looks like text is converted to\nuse LF.\n\nUsing .gitattributes you can override the autodetection (see\nconvert.c::is_binary) of text files.\n\n>>\t[core]\n>>\t\teol = lf\n>\n> So this changes the file in the repository to lf only, but not in\n> the worktree? That's what I want.\n\nThe opposite.  This makes the file in the worktree use lf on\ncheckout, if it is known to be a text file.\n\nOn Linux it is a no-op.  For files known to be text files, the version\nchecked in _always_ uses LF anyway.  The setting \"[core] eol = lf\" is\njust a way to turn off \"[core] eol = crlf\".\n\n> In the tracked tree? The documentation:\n> \n> http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_checking_out_and_checking_in\n> \n> says it goes in:\n> \n>  $GIT_DIR/info/attributes, .gitattributes\n> \n> so I'm confused again. Does .gitattributes go in $GIT_DIR, or in\n> $GIT_DIR/info ? And what if both of those files are there, which one\n> 'wins' ?\n\nThough I said \"in the tracked tree\", it is generally the file in the\nworktree that counts.  There can be .gitattributes files in any\nsubdirectory of the toplevel of the work tree.\n\n.git/info/attributes is a place to put local attribute settings that\nshould not be tracked.  It has higher precedence than the\n.gitattributes files.  As the gitattributes(5) page says:\n\n\tgit consults $GIT_DIR/info/attributes file (which has the\n\thighest precedence), .gitattributes file in the same\n\tdirectory as the path in question, and its parent\n\tdirectories up to the toplevel of the work tree (the\n\tfurther the directory that contains .gitattributes is\n\tfrom the path in question, the lower its precedence).\n\n>> If everyone for which you want these setting to take effect uses a\n>> recent version of git, you can write “text” instead of “crlf” if\n>> you prefer.\n>\n> git --version says I'm using 1.5.6.3\n\nNot recent enough. :)\n\nActually versions before 1.7.2 do not have the \"[core] eol\"\nconfiguration, either, so there is one less thing to worry about.\n\n> A final question: where does the repository actually go (so I can\n> back it up)?\n\nThe subdirectory .git of the top level of the worktree.\n\nYou can back up with \"git clone\" or \"git bundle\", but copying the\n.git directory also works fine.\n\nRegards,\nJonathan\n"},{"id":"146841","messageId":"i30da5$84d$1@dough.gmane.org","threadId":"24588","inReplyTo":"20100731053918.GA19688@LK-Perkele-V2.elisa-laajakaista.fi","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Walter Bright","fromEmail":"boost@digitalmars.com","sentAt":"2010-07-31T05:45:36Z","receivedAt":"2010-07-31T05:45:36Z","isPatch":false,"sender":{"key":"boost@digitalmars.com","avatar":null},"body":"Ilari Liusvaara wrote:\n> On Fri, Jul 30, 2010 at 10:14:40PM -0700, Walter Bright wrote:\n>> A final question: where does the repository actually go (so I can\n>> back it up)? This is a local thing, I'm not trying to set up a\n>> networked or remote repository, so it'll be the default location.\n> \n> .git directory in root of working copy. One way to backup is just\n> to do recursive backup of entiere working copy[1].\n> \n> [1] But upon restore, the working copy cache will be wrong\n\nWhy? Is it someplace else?\n\n> and needs to be rebuilt (git update-index --refresh).\n"},{"id":"146842","messageId":"20100731055735.GA19812@LK-Perkele-V2.elisa-laajakaista.fi","threadId":"24588","inReplyTo":"i30da5$84d$1@dough.gmane.org","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2010-07-31T05:57:35Z","receivedAt":"2010-07-31T05:57:35Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Fri, Jul 30, 2010 at 10:45:36PM -0700, Walter Bright wrote:\n\n> >[1] But upon restore, the working copy cache will be wrong\n> \n> Why? Is it someplace else?\n\nIt is inside .git directory and will be caught by full recursive\nbackup. Unfortunately, it contains i-node numbers, which aren't\npreserved through backup and restore.\n\nThe wrong i-node numbers would then confuse git (false positives\nin modification detection). Fortunately, this data can be rebuilt\nwith single command (see below).\n \n> >and needs to be rebuilt (git update-index --refresh).\n\n-Ilari\n"},{"id":"146850","messageId":"i30fj8$cit$1@dough.gmane.org","threadId":"24588","inReplyTo":"20100731055735.GA19812@LK-Perkele-V2.elisa-laajakaista.fi","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Walter Bright","fromEmail":"boost@digitalmars.com","sentAt":"2010-07-31T06:24:34Z","receivedAt":"2010-07-31T06:24:34Z","isPatch":false,"sender":{"key":"boost@digitalmars.com","avatar":null},"body":"Ilari Liusvaara wrote:\n> On Fri, Jul 30, 2010 at 10:45:36PM -0700, Walter Bright wrote:\n> \n>>> [1] But upon restore, the working copy cache will be wrong\n>> Why? Is it someplace else?\n> \n> It is inside .git directory and will be caught by full recursive\n> backup. Unfortunately, it contains i-node numbers, which aren't\n> preserved through backup and restore.\n> \n> The wrong i-node numbers would then confuse git (false positives\n> in modification detection). Fortunately, this data can be rebuilt\n> with single command (see below).\n\nHmm. One thing I wanted to get away from from Windows was the inability to \nrestore files by just copying the tree.\n\n\n>>> and needs to be rebuilt (git update-index --refresh).\n\nThat's crucial to know. Thanks!\n"},{"id":"146851","messageId":"i30g2s$dpt$1@dough.gmane.org","threadId":"24588","inReplyTo":"20100731054437.GD14425@burratino","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Walter Bright","fromEmail":"boost@digitalmars.com","sentAt":"2010-07-31T06:32:53Z","receivedAt":"2010-07-31T06:32:53Z","isPatch":false,"sender":{"key":"boost@digitalmars.com","avatar":null},"body":"Jonathan Nieder wrote:\n> Hi again,\n> \n> Some clarifications.\n> \n> Walter Bright wrote:\n> \n>> git is installed under Ubuntu, but I'll be checking in files that I\n>> edit on both Windows and Ubuntu, so the line endings will vary\n>> depending on which platform I last editted the file on. Hence, I\n>> want to force them all to be LF upon checkin.\n> \n> \"[core] autocrlf = input\" would work.  With this setting, the work\n> tree is considered sacred (i.e., not touched in any magical way at\n> all) but content checked in that looks like text is converted to\n> use LF.\n> \n> Using .gitattributes you can override the autodetection (see\n> convert.c::is_binary) of text files.\n> \n>>> \t[core]\n>>> \t\teol = lf\n>> So this changes the file in the repository to lf only, but not in\n>> the worktree? That's what I want.\n> \n> The opposite.  This makes the file in the worktree use lf on\n> checkout, if it is known to be a text file.\n> \n> On Linux it is a no-op.  For files known to be text files, the version\n> checked in _always_ uses LF anyway.  The setting \"[core] eol = lf\" is\n> just a way to turn off \"[core] eol = crlf\".\n\nSo I'm lost again. If the version in the repository is always converted to LF, \nthen why do I need to set autocrlf=input ?\n\n\n> \n>> In the tracked tree? The documentation:\n>>\n>> http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_checking_out_and_checking_in\n>>\n>> says it goes in:\n>>\n>>  $GIT_DIR/info/attributes, .gitattributes\n>>\n>> so I'm confused again. Does .gitattributes go in $GIT_DIR, or in\n>> $GIT_DIR/info ? And what if both of those files are there, which one\n>> 'wins' ?\n> \n> Though I said \"in the tracked tree\", it is generally the file in the\n> worktree that counts.  There can be .gitattributes files in any\n> subdirectory of the toplevel of the work tree.\n> \n> .git/info/attributes is a place to put local attribute settings that\n> should not be tracked.  It has higher precedence than the\n> .gitattributes files.  As the gitattributes(5) page says:\n> \n> \tgit consults $GIT_DIR/info/attributes file (which has the\n> \thighest precedence), .gitattributes file in the same\n> \tdirectory as the path in question, and its parent\n> \tdirectories up to the toplevel of the work tree (the\n> \tfurther the directory that contains .gitattributes is\n> \tfrom the path in question, the lower its precedence).\n\nOk, got it!\n\n> \n>>> If everyone for which you want these setting to take effect uses a\n>>> recent version of git, you can write “text” instead of “crlf” if\n>>> you prefer.\n>> git --version says I'm using 1.5.6.3\n> \n> Not recent enough. :)\n\nEh, it's what ubuntu's apt-get gave me.\n\n\n> Actually versions before 1.7.2 do not have the \"[core] eol\"\n> configuration, either, so there is one less thing to worry about.\n> \n>> A final question: where does the repository actually go (so I can\n>> back it up)?\n> \n> The subdirectory .git of the top level of the worktree.\n> \n> You can back up with \"git clone\" or \"git bundle\", but copying the\n> .git directory also works fine.\n\nWhy would \"git clone\" even exist if copying the directory works? Is it the \nembedded inode problem that Ilari mentioned?\n"},{"id":"146852","messageId":"20100731064102.GA20106@LK-Perkele-V2.elisa-laajakaista.fi","threadId":"24588","inReplyTo":"i30g2s$dpt$1@dough.gmane.org","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2010-07-31T06:41:02Z","receivedAt":"2010-07-31T06:41:02Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Fri, Jul 30, 2010 at 11:32:53PM -0700, Walter Bright wrote:\n> \n> Why would \"git clone\" even exist if copying the directory works? Is\n> it the embedded inode problem that Ilari mentioned?\n\nCloning remote repositories. But there are URLs for local repositories\ntoo, so those can be cloned as well.\n\n-Ilari\n"},{"id":"146864","messageId":"20100731151209.GA5693@gmail.com","threadId":"24588","inReplyTo":"i30fj8$cit$1@dough.gmane.org","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2010-07-31T15:12:12Z","receivedAt":"2010-07-31T15:12:12Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Fri, Jul 30, 2010 at 11:24:34PM -0700, Walter Bright wrote:\n> Ilari Liusvaara wrote:\n> >On Fri, Jul 30, 2010 at 10:45:36PM -0700, Walter Bright wrote:\n> >\n> >>>[1] But upon restore, the working copy cache will be wrong\n> >>Why? Is it someplace else?\n> >\n> >It is inside .git directory and will be caught by full recursive\n> >backup. Unfortunately, it contains i-node numbers, which aren't\n> >preserved through backup and restore.\n> >\n> >The wrong i-node numbers would then confuse git (false positives\n> >in modification detection). Fortunately, this data can be rebuilt\n> >with single command (see below).\n> \n> Hmm. One thing I wanted to get away from from Windows was the\n> inability to restore files by just copying the tree.\n\nI think we gave you too much information.\nJust copy the tree, that's all there is to see here...\n\n\n> >>>and needs to be rebuilt (git update-index --refresh).\n> \n> That's crucial to know. Thanks!\n\nActually, I think that's too much to know.\n\nCasual git users can just say 'git status' and git\nwill DTRT updating the index itself.\n\nSorry if the information in this thread made you\nthink that there's \"something else\" that you have to\nworry about backing up.  Nope, it's all just .git.\n\n-- \n\t\tDavid\n"},{"id":"146872","messageId":"20100731203820.GA1773@burratino","threadId":"24588","inReplyTo":"i30g2s$dpt$1@dough.gmane.org","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-31T20:38:20Z","receivedAt":"2010-07-31T20:38:20Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Walter Bright wrote:\n\n> Why would \"git clone\" even exist if copying the directory works?\n\nAs Ilari said, it works remotely.  It’s even faster than just copying\nthe directory (since it has to do less reading), and it only copies\nthe repository, not the work tree or .git/config, which may or may not\nbe what you want.\n\nMore importantly, the reason I mentioned it was this: if you clone\nto make your first backup, you are more likely (when appropriate) to\nuse \"git fetch\" instead of rsync to update the backup afterwards.\nAnd for that operation, \"git fetch\" is much more efficient.\n\nAnyway, feel free to ignore this advice.  \"cp -a\" works fine already\nand is sometimes just the right thing to do.\n\nJonathan\n"},{"id":"146873","messageId":"i322ca$niu$1@dough.gmane.org","threadId":"24588","inReplyTo":"20100731203820.GA1773@burratino","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Walter Bright","fromEmail":"boost@digitalmars.com","sentAt":"2010-07-31T20:51:15Z","receivedAt":"2010-07-31T20:51:15Z","isPatch":false,"sender":{"key":"boost@digitalmars.com","avatar":null},"body":"Jonathan Nieder wrote:\n> Anyway, feel free to ignore this advice.  \"cp -a\" works fine already\n> and is sometimes just the right thing to do.\n\nThanks for the info. I am so thoroughly fed up with applications that store \ntheir data in ways that cannot be backed up / restored with straightforward file \ntree copying. I don't know why anyone else puts up with that, either.\n"},{"id":"147081","messageId":"AANLkTim=avirVOZ99_Pgp1iLJQ_5J_1xpAad84boi_M3@mail.gmail.com","threadId":"24588","inReplyTo":"i30g2s$dpt$1@dough.gmane.org","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-08-03T23:56:42Z","receivedAt":"2010-08-03T23:56:42Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sat, Jul 31, 2010 at 2:32 AM, Walter Bright <boost@digitalmars.com> wrote:\n> So I'm lost again. If the version in the repository is always converted to\n> LF, then why do I need to set autocrlf=input ?\n\nLet's start over. :-)\n\nBefore git-1.7.2, EOL conversion was rather insane. It's fixed in\n1.7.2, so I'm going to start by explaining what happens with that\nversion and later.\n\nOption 1 (text/eol attributes):\n\n- Normally git will perform no EOL conversion. Files are committed\ninto the repo exactly as you see them in your checkout.\n\n- To have git perform EOL conversion, you need to either explicitly\ntell it which files are text, or let it autodetect. You normally do\nthis via the .gitattributes file using:\n\n  <pattern> text\n\nor\n\n  * text=auto\n\nIn the former case, you're telling git explicitly which files are\ntext. In the latter case, you're telling git to do its best to detect\nwhich files are text.\n\nFiles which are explicitly tagged as text, or auto-detected as text,\nwill have their EOLs converted to LF on check-in, and converted to\ncore.eol on check-out. core.eol defaults to \"native\" which means LF on\nUnix and CRLF on Cygwin, but you can explicitly set it to \"lf\" or\n\"crlf\" if you desire.\n\nCertain files you may wish to specify their EOL in the working copy\nexplicitly. You do this with the eol attribute. e.g.:\n\n  <pattern> eol=crlf\n  <pattern> eol=lf\n\nFiles which are tagged with eol={crlf,lf} are implicitly text, and\nwill have their EOLs converted to LF on check-in, and converted to the\nspecified EOL on check-out.\n\nOkay, so that's how you ensure that certain files have LFs in the\nrepo, and the desired EOL in the working-copy.\n\nOption 2 (core.autocrlf):\n\nWith core.autocrlf=true, any files in the repo that git detects as\ntext and which already have LF EOLs will have their EOLs converted to\nCRLF on check-out. Also, any additions to these files, or any new\nfiles that git detects as text, will have their EOLs converted to LF\non check-in.\n\nIn this way, core.autocrlf=true is similar to \"* text=auto\", however\nit does not affect any files in the repo which already have CRLF EOLs.\n\nAFAIK, there's no reason to set core.autocrlf=true on Unix. You'd\ntypically only set it under Windows.\n\nI'm going to stop here as I think these are the only options that make\nsense with 1.7.2 and above. If you want me to explain your options\nusing earlier versions of git, I can try, but it's even more\nconfusing.\n\nj.\n"},{"id":"147094","messageId":"1280899775.2820.4.camel@dreddbeard","threadId":"24588","inReplyTo":"AANLkTim=avirVOZ99_Pgp1iLJQ_5J_1xpAad84boi_M3@mail.gmail.com","subject":"Re: noob user, want checkins to all be forced to LF terminated lines","fromName":"Will Palmer","fromEmail":"wmpalmer@gmail.com","sentAt":"2010-08-04T05:29:35Z","receivedAt":"2010-08-04T05:29:35Z","isPatch":false,"sender":{"key":"wmpalmer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/357044?v=4"},"body":"On Tue, 2010-08-03 at 19:56 -0400, Jay Soffian wrote:\n> On Sat, Jul 31, 2010 at 2:32 AM, Walter Bright <boost@digitalmars.com> wrote:\n> > So I'm lost again. If the version in the repository is always converted to\n> > LF, then why do I need to set autocrlf=input ?\n> \n> Let's start over. :-)\n> \n> Before git-1.7.2, EOL conversion was rather insane. It's fixed in\n> 1.7.2, so I'm going to start by explaining what happens with that\n> version and later.\n> \n> Option 1 (text/eol attributes):\n> \n> - Normally git will perform no EOL conversion. Files are committed\n> into the repo exactly as you see them in your checkout.\n> \n> - To have git perform EOL conversion, you need to either explicitly\n> tell it which files are text, or let it autodetect. You normally do\n> this via the .gitattributes file using:\n> \n>   <pattern> text\n> \n> or\n> \n>   * text=auto\n> \n> In the former case, you're telling git explicitly which files are\n> text. In the latter case, you're telling git to do its best to detect\n> which files are text.\n> \n> Files which are explicitly tagged as text, or auto-detected as text,\n> will have their EOLs converted to LF on check-in, and converted to\n> core.eol on check-out. core.eol defaults to \"native\" which means LF on\n> Unix and CRLF on Cygwin, but you can explicitly set it to \"lf\" or\n> \"crlf\" if you desire.\n> \n> Certain files you may wish to specify their EOL in the working copy\n> explicitly. You do this with the eol attribute. e.g.:\n> \n>   <pattern> eol=crlf\n>   <pattern> eol=lf\n> \n> Files which are tagged with eol={crlf,lf} are implicitly text, and\n> will have their EOLs converted to LF on check-in, and converted to the\n> specified EOL on check-out.\n> \n> Okay, so that's how you ensure that certain files have LFs in the\n> repo, and the desired EOL in the working-copy.\n> \n> Option 2 (core.autocrlf):\n> \n> With core.autocrlf=true, any files in the repo that git detects as\n> text and which already have LF EOLs will have their EOLs converted to\n> CRLF on check-out. Also, any additions to these files, or any new\n> files that git detects as text, will have their EOLs converted to LF\n> on check-in.\n> \n> In this way, core.autocrlf=true is similar to \"* text=auto\", however\n> it does not affect any files in the repo which already have CRLF EOLs.\n> \n> AFAIK, there's no reason to set core.autocrlf=true on Unix. You'd\n> typically only set it under Windows.\n> \n> I'm going to stop here as I think these are the only options that make\n> sense with 1.7.2 and above. If you want me to explain your options\n> using earlier versions of git, I can try, but it's even more\n> confusing.\n> \n> j.\n\nIf it is accurate (and I have no way of knowing, since I've never\nunderstood the ins-and-outs before), then that was the best, most\nstraightforward, most complete, least confusing description of\ncore.autocrlf, eol={crlf,lf}, and text=auto that I have ever read. I\nwant this post re-formatted and included in the docs :)\n\nFor completeness, would you mind explaining the \"old way\" too, and\ninclude a note on oddities such as \"git says my entire working copy has\nchanged, but reset --hard does nothing\"? I just feel like I'm closer\nthan I've ever been to understanding the whole mess.\n\n\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-- \n-- Will\n"}]}