{"thread":{"id":"20044","subject":"Schrödinger's diff","startedAt":"2009-07-07T06:53:47Z","lastAt":"2009-07-08T06:13:01Z","messageCount":13,"participants":["Eric Raible","Johannes Sixt","Andreas Ericsson","Daniel Barkalow","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"117539","messageId":"279b37b20907062353k34bca06erf035458e80933c8d@mail.gmail.com","threadId":"20044","inReplyTo":null,"subject":"Schrödinger's diff","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2009-07-07T06:53:47Z","receivedAt":"2009-07-07T06:53:47Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"git version 1.6.3.2.1299.gee46c (msysgit)\n\nIn trying to track down some annoying crlf corruption in a repo\nI have found a Schrödinger's diff.  In other words it's unknown\nwhether the diff will produce output or not on any particular run\nof the following script.\n\nSometimes it does, and sometimes it doesn't (seems to be about\n50/50).  But either way in any given repo rerunning the git-diff will\nalways give the same result.\n\nDoing an \"git ls-tree HEAD\" gives an identical tree in both cases.\n\nCan anyone explain why the output to this is not deterministic?\nI'm at a complete loss.\n\n\t# Clean up from last run and start over\n\trm -rf .git has-crlf\n\tgit init\n\tgit config core.autocrlf false\n\n\t# Add a \"bad\" file\n\tperl -e 'printf( \"12%c%c\", 0xd, 0xa )' > has-crlf\n\tgit add has-crlf\n\tgit commit -m\"add crlf\"\n\n\t# I realize that switching is ill-advised, but I'm\n\t# trying to track down a possibly related problem...\n\tgit config core.autocrlf true\n\n\t# This sometimes produces output and sometimes it doesn't.\n\t# Either way rerunning just git-diff always gives the same result\n\t# as the first run in this repo.\n\tgit diff\n\n- Eric\n"},{"id":"117542","messageId":"4A52F90D.7080305@viscovery.net","threadId":"20044","inReplyTo":"279b37b20907062353k34bca06erf035458e80933c8d@mail.gmail.com","subject":"Re: Schrödinger's diff","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-07-07T07:28:13Z","receivedAt":"2009-07-07T07:28:13Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Eric Raible schrieb:\n> Sometimes it does, and sometimes it doesn't (seems to be about\n> 50/50).  But either way in any given repo rerunning the git-diff will\n> always give the same result.\n> \n> Doing an \"git ls-tree HEAD\" gives an identical tree in both cases.\n> \n> Can anyone explain why the output to this is not deterministic?\n> I'm at a complete loss.\n> \n> \t# Clean up from last run and start over\n> \trm -rf .git has-crlf\n> \tgit init\n> \tgit config core.autocrlf false\n> \n> \t# Add a \"bad\" file\n> \tperl -e 'printf( \"12%c%c\", 0xd, 0xa )' > has-crlf\n> \tgit add has-crlf\n> \tgit commit -m\"add crlf\"\n> \n> \t# I realize that switching is ill-advised, but I'm\n> \t# trying to track down a possibly related problem...\n> \tgit config core.autocrlf true\n> \n> \t# This sometimes produces output and sometimes it doesn't.\n> \t# Either way rerunning just git-diff always gives the same result\n> \t# as the first run in this repo.\n> \tgit diff\n\nIf I put this in a script, I get a diff in 9 out of 10 runs. If I insert\n'sleep 1' right before the 'git add', I never get a diff.\n\nI'm handing this off to people who care about core.autocrlf and who know\nhow racily-clean index entries (not) work ;)\n\n-- Hannes\n"},{"id":"117543","messageId":"4A52FEAE.90705@op5.se","threadId":"20044","inReplyTo":"279b37b20907062353k34bca06erf035458e80933c8d@mail.gmail.com","subject":"Re: Schrödinger's diff","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-07-07T07:52:14Z","receivedAt":"2009-07-07T07:52:14Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Eric Raible wrote:\n> git version 1.6.3.2.1299.gee46c (msysgit)\n> \n> In trying to track down some annoying crlf corruption in a repo\n> I have found a Schrödinger's diff.  In other words it's unknown\n> whether the diff will produce output or not on any particular run\n> of the following script.\n> \n> Sometimes it does, and sometimes it doesn't (seems to be about\n> 50/50).  But either way in any given repo rerunning the git-diff will\n> always give the same result.\n> \n\nI don't get the same result in the same repo, although it only\ndiffers in 1-1.5% of the tests.\n\n> Doing an \"git ls-tree HEAD\" gives an identical tree in both cases.\n> \n> Can anyone explain why the output to this is not deterministic?\n\nOn Linux with git version 1.6.3.3.354.g3b4cc\n\nPasting your commands into \"repro.sh\", but redirecting output from\ngit commit to /dev/null, and then running the following commands\nhas yielded 9 to 15 sample.$i files over 5 tries of the following:\n\nsh repro.sh > correct\nfor i in $(seq 1 1000); do\n  sh repro.sh > sample && cmp sample correct >/dev/null || \\\n     { echo \"fail $i\" && cp sample sample.$i; };\ndone\n\n> I'm at a complete loss.\n> \n\nInserting \"sync\" between calls as shown below doesn't fix the issue\n(although it drops from 9-15 to 4-10 fails on Linux; Not a very good\nimprovement and only two test-runs). I have no idea how it can behave\nso strangely, and I refuse to believe that the ext3 fs driver allows\ndirty reads.\n\n> \t# Clean up from last run and start over\n> \trm -rf .git has-crlf\n> \tgit init\n> \tgit config core.autocrlf false\n> \n> \t# Add a \"bad\" file\n> \tperl -e 'printf( \"12%c%c\", 0xd, 0xa )' > has-crlf\n> \tgit add has-crlf\n> \tgit commit -m\"add crlf\"\n> \n\nsync\n\n> \t# I realize that switching is ill-advised, but I'm\n> \t# trying to track down a possibly related problem...\n> \tgit config core.autocrlf true\n> \n\nsync\n\n> \t# This sometimes produces output and sometimes it doesn't.\n> \t# Either way rerunning just git-diff always gives the same result\n> \t# as the first run in this repo.\n> \tgit diff\n> \n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"117571","messageId":"alpine.LNX.2.00.0907071316490.2147@iabervon.org","threadId":"20044","inReplyTo":"279b37b20907062353k34bca06erf035458e80933c8d@mail.gmail.com","subject":"Re: Schrödinger's diff","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-07-07T17:36:08Z","receivedAt":"2009-07-07T17:36:08Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 6 Jul 2009, Eric Raible wrote:\n\n> git version 1.6.3.2.1299.gee46c (msysgit)\n> \n> In trying to track down some annoying crlf corruption in a repo\n> I have found a Schrödinger's diff.  In other words it's unknown\n> whether the diff will produce output or not on any particular run\n> of the following script.\n> \n> Sometimes it does, and sometimes it doesn't (seems to be about\n> 50/50).  But either way in any given repo rerunning the git-diff will\n> always give the same result.\n> \n> Doing an \"git ls-tree HEAD\" gives an identical tree in both cases.\n> \n> Can anyone explain why the output to this is not deterministic?\n> I'm at a complete loss.\n> \n> \t# Clean up from last run and start over\n> \trm -rf .git has-crlf\n> \tgit init\n> \tgit config core.autocrlf false\n> \n> \t# Add a \"bad\" file\n> \tperl -e 'printf( \"12%c%c\", 0xd, 0xa )' > has-crlf\n> \tgit add has-crlf\n\nIf has-crlf and .git/index have the same timestamp, git does not know \nwhether the file has been modified afterwards or not. If they have \ndifferent timestamps, git knows the file hasn't been modified after the \nadd. (More precisely, the index contains the mtime of the file, and it \nwill agree with the file system. However, if the timestamp on the index \nmatches a timestamp *in* the index, that means that, when the index was \nwritten, the time period represented by that timestamp was not yet over \nwhen git looked at the file. Therefore, the file could have changed \nagain after that time and still gotten the same timestamp it already had. \nThis means that git can't be sure that there's nothing new to see in the \nfilesystem.)\n\n> \tgit commit -m\"add crlf\"\n> \n> \t# I realize that switching is ill-advised, but I'm\n> \t# trying to track down a possibly related problem...\n> \tgit config core.autocrlf true\n> \n> \t# This sometimes produces output and sometimes it doesn't.\n> \t# Either way rerunning just git-diff always gives the same result\n> \t# as the first run in this repo.\n> \tgit diff\n\nIf git knows the file hasn't been modified, it doesn't produce a diff. \n\nIf it doesn't know the file hasn't been modified, it looks at the actual \ncontents and it find that the result of reading the disk applying autocrlf \nnow doesn't match the contents of the index.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"117577","messageId":"20090707193605.GA30945@coredump.intra.peff.net","threadId":"20044","inReplyTo":"alpine.LNX.2.00.0907071316490.2147@iabervon.org","subject":"Re: Schrödinger's diff","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-07-07T19:36:05Z","receivedAt":"2009-07-07T19:36:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 07, 2009 at 01:36:08PM -0400, Daniel Barkalow wrote:\n\n> > \t# I realize that switching is ill-advised, but I'm\n> > \t# trying to track down a possibly related problem...\n> > \tgit config core.autocrlf true\n> > \n> > \t# This sometimes produces output and sometimes it doesn't.\n> > \t# Either way rerunning just git-diff always gives the same result\n> > \t# as the first run in this repo.\n> > \tgit diff\n> \n> If git knows the file hasn't been modified, it doesn't produce a diff. \n> \n> If it doesn't know the file hasn't been modified, it looks at the actual \n> contents and it find that the result of reading the disk applying autocrlf \n> now doesn't match the contents of the index.\n\nYes, that was my analysis upon reading the original mail, as well (and I\nhave been bitten by this before while testing crlf stuff). The same\nthing can happen with clean/smudge, I think.\n\nWhen you set up config that changes how we view worktree files (like\ncrlf or clean/smudge) and there is already cached stat information in\nthe index, you really need to invalidate the matching stat information\nin the index to get sane results[1]. It might be nice for \"git config\"\nto do this for you, but:\n\n    1. You could just as easily be hand-editing the config.\n\n    2. It feels wrong from a modularity standpoint. Right now \"git\n       config\" doesn't actually care about the semantics of config,\n       just the syntax. Which makes it exactly equivalent to\n       hand-editing.\n\n    3. It doesn't cover every situation. Files can also be \"changed\" in\n       this way by editing .gitattributes, which can be changed manually\n       or by any number of git commands (like checkout, reset, etc).\n\nSo I think automatically detecting this situation would require flags in\nthe index to say \"this stat information is valid only over these\nparticular settings\". And you would want it per-file to avoid having to\nre-hash every file when you change the .gitattributes for one file. The\ncommand using the index would check it. But even that might have holes,\nI'm afraid -- we don't always look at all of the config in every\ncommand, though perhaps we do for such core functionality.\n\n-Peff\n\n[1] Is there an easy way to do this with update-index? I didn't see one,\nand had to resort to \"git read-tree HEAD\".\n"},{"id":"117578","messageId":"7vtz1o9sv6.fsf@alter.siamese.dyndns.org","threadId":"20044","inReplyTo":"20090707193605.GA30945@coredump.intra.peff.net","subject":"Re: Schrödinger's diff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-07T19:48:45Z","receivedAt":"2009-07-07T19:48:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> .... But even that might have holes,\n> I'm afraid -- we don't always look at all of the config in every\n> command, though perhaps we do for such core functionality.\n\nI personally do not think it is worth it.  If you change the crlf,\nclean/smudge, or anything of that sort, just doing a \"rm .git/index\"\nfollowed by \"git reset --hard\" would restore sanity to your work tree, no?\n"},{"id":"117579","messageId":"20090707195406.GA32131@coredump.intra.peff.net","threadId":"20044","inReplyTo":"7vtz1o9sv6.fsf@alter.siamese.dyndns.org","subject":"Re: Schrödinger's diff","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-07-07T19:54:06Z","receivedAt":"2009-07-07T19:54:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 07, 2009 at 12:48:45PM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > .... But even that might have holes,\n> > I'm afraid -- we don't always look at all of the config in every\n> > command, though perhaps we do for such core functionality.\n> \n> I personally do not think it is worth it.  If you change the crlf,\n> clean/smudge, or anything of that sort, just doing a \"rm .git/index\"\n> followed by \"git reset --hard\" would restore sanity to your work tree, no?\n\nYes, that works fine, but:\n\n  1. It blows away anything unrelated you might have staged.\n\n  2. You have to know to do it (and you get very confusing results if\n     you don't), which makes it very unfriendly for newbies.\n\n  3. You have to know to do it, and it isn't documented. :)\n\n(3) at least is not too hard to address. And perhaps (2) is not a big\nenough issue to care about. This is not a problem we have seen on the\nlist a lot. I suspect it is because most CRLF users are on Windows, and\ntherefore have it setup before the tree is checked out, and there are\nsimply not all that many clean/smudge users.\n\n-Peff\n"},{"id":"117590","messageId":"279b37b20907071330y732fad4dxe4e21edeab9ff179@mail.gmail.com","threadId":"20044","inReplyTo":"7vtz1o9sv6.fsf@alter.siamese.dyndns.org","subject":"Re: Schrödinger's diff","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2009-07-07T20:30:47Z","receivedAt":"2009-07-07T20:30:47Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Tue, Jul 7, 2009 at 12:48 PM, Junio C Hamano<gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>> .... But even that might have holes,\n>> I'm afraid -- we don't always look at all of the config in every\n>> command, though perhaps we do for such core functionality.\n>\n> I personally do not think it is worth it.  If you change the crlf,\n> clean/smudge, or anything of that sort, just doing a \"rm .git/index\"\n> followed by \"git reset --hard\" would restore sanity to your work tree, no?\n\nIs there any technical reason why \"git reset --hard\" shouldn't repopulate\nthe index by doing a \"git read-tree\" or equivalent [1]?  After all the\ndocs claim it\n\"Matches the working tree and index to that of the tree being switched to\".\n\nExcept in this case it doesn't.  The resulting .index is an invalid\nrepresentation\nof the tree.  Sanity can be restored with \"git read-tree HEAD\" (as\nJeff suggested),\nbut that's hardly intuitive.\n\n- Eric\n\n[1] For instance anything at all (possibly involving time stamps) such that\nthe index will truly match the tree.\n"},{"id":"117591","messageId":"20090707204806.GA1278@coredump.intra.peff.net","threadId":"20044","inReplyTo":"279b37b20907071330y732fad4dxe4e21edeab9ff179@mail.gmail.com","subject":"Re: Schrödinger's diff","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-07-07T20:48:06Z","receivedAt":"2009-07-07T20:48:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 07, 2009 at 01:30:47PM -0700, Eric Raible wrote:\n\n> > I personally do not think it is worth it.  If you change the crlf,\n> > clean/smudge, or anything of that sort, just doing a \"rm .git/index\"\n> > followed by \"git reset --hard\" would restore sanity to your work tree, no?\n> \n> Is there any technical reason why \"git reset --hard\" shouldn't repopulate\n> the index by doing a \"git read-tree\" or equivalent [1]?  After all the\n> docs claim it\n> \"Matches the working tree and index to that of the tree being switched to\".\n\nYes; relying on the stat cache is what makes \"git reset --hard\" really\nfast, instead of having to re-hash each file. The real problem is that\nwe are invalidating the contents of that cache, but not marking the\nentry as dirty.\n\nRight now we don't mark the entries, and you get stale data until you\nmanually mark them as dirty. But marking them dirty on every reset will\nmean that reset can't make use of the cache, which is slow. So ideally\nwe would have a way of marking them dirty only when necessary. One way\nwould be a \"git reset --hard --reset-me-harder\", but that obviously\nstill involves manual work; you're just making the command a little\neasier to find and use.\n\nAs I suggested before, you could include the changed bits (i.e., the\nattributes and config) as part of the cache validity information.  But I\nsuspect it would be hard to implement, as it involves new fields in the\nindex. It also involves arbitrary user commands, so getting it 100%\nright would be impossible (e.g., we can record the string\n\"my-clean-filter\" as the filter name, but we can't know when that\nfilter's behavior has changed); however, in practice, I think we can\nassume that a string containing a text command will have stable output.\n\n-Peff\n"},{"id":"117597","messageId":"7vfxd89lqf.fsf@alter.siamese.dyndns.org","threadId":"20044","inReplyTo":"20090707195406.GA32131@coredump.intra.peff.net","subject":"Re: Schrödinger's diff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-07T22:22:48Z","receivedAt":"2009-07-07T22:22:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Yes, that works fine, but:\n>\n>   1. It blows away anything unrelated you might have staged.\n>\n>   2. You have to know to do it (and you get very confusing results if\n>      you don't), which makes it very unfriendly for newbies.\n>\n>   3. You have to know to do it, and it isn't documented. :)\n>\n> (3) at least is not too hard to address. And perhaps (2) is not a big\n> enough issue to care about. This is not a problem we have seen on the\n> list a lot. I suspect it is because most CRLF users are on Windows, and\n> therefore have it setup before the tree is checked out, and there are\n> simply not all that many clean/smudge users.\n\nA much more important reason is that it is a one-time event.  You notice\nthat you screwed up the configuration to use your peculiar work tree\nrepresentation, and you fix it once and for all.  Because not only it is a\none-time event but because it is a big-deal event, I do not think it is\nsomething people even would want to think about doing it while having\nlocal changes, so I suspect #1 is also a non-issue.\n"},{"id":"117599","messageId":"279b37b20907071717r71f982b6u7333ff10fadfc39@mail.gmail.com","threadId":"20044","inReplyTo":"7vfxd89lqf.fsf@alter.siamese.dyndns.org","subject":"Re: Schrödinger's diff","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2009-07-08T00:17:21Z","receivedAt":"2009-07-08T00:17:21Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Tue, Jul 7, 2009 at 3:22 PM, Junio C Hamano<gitster@pobox.com> wrote:\n> You notice\n> that you screwed up the configuration to use your peculiar work tree\n> representation, and you fix it once and for all.\n\nA kinda dim-witted question:\n\nSo what's the best way of \"fixing once and for all\" a repo infected with\ncarriage returns when you want to use autocrlf=true moving forward?\n\nAnd a hopefully less annoying one:\n\nWould you accept a patch explaining how \"git reset --hard\" doesn't\nactually rebuild the index from scratch, and how \"git read-head\" might\nbe recommended in some weird situations?\n"},{"id":"117601","messageId":"7v8wizanqr.fsf@alter.siamese.dyndns.org","threadId":"20044","inReplyTo":"279b37b20907071717r71f982b6u7333ff10fadfc39@mail.gmail.com","subject":"Re: Schrödinger's diff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-08T02:54:04Z","receivedAt":"2009-07-08T02:54:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Raible <raible@gmail.com> writes:\n\n> So what's the best way of \"fixing once and for all\" a repo infected with\n> carriage returns when you want to use autocrlf=true moving forward?\n\nDidn't \"rm -f .git/index && git reset --hard HEAD\" work?\n\n> And a hopefully less annoying one:\n>\n> Would you accept a patch explaining how \"git reset --hard\" doesn't\n> actually rebuild the index from scratch,...\n\nAbsolutely.\n\n> ... and how \"git read-head\" might\n> be recommended in some weird situations?\n\nI am less certain about that; people may have easier-to-read solution than\nthe one with read-tree, I would suspect.\n"},{"id":"117608","messageId":"279b37b20907072313t79ddded2k84c819887c234e8b@mail.gmail.com","threadId":"20044","inReplyTo":"7v8wizanqr.fsf@alter.siamese.dyndns.org","subject":"Re: Schrödinger's diff","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2009-07-08T06:13:01Z","receivedAt":"2009-07-08T06:13:01Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Tue, Jul 7, 2009 at 7:54 PM, Junio C Hamano<gitster@pobox.com> wrote:\n> Eric Raible <raible@gmail.com> writes:\n>\n>> So what's the best way of \"fixing once and for all\" a repo infected with\n>> carriage returns when you want to use autocrlf=true moving forward?\n>\n> Didn't \"rm -f .git/index && git reset --hard HEAD\" work?\n\nWill, it \"worked\" in the sense that it usually [1] allows\n\"git diff --name-only\" to correctly show the files that were\nchecked in with crlf endings and core.autocrlf false.\n\nThose files are then out-of-date when core.autocrlf is\ntrue and .git/index is up-to-date.\n\nIn other words, that first step worked around the fact\nthat sometimes that .git/index was out of date.\n\nBy \"fixing it once and for all\" I was trying to refer to creating\nthe correct commit to abolish the carriage returns from my repo.\n\nI ended up with this crude-but-obvious loop which\ngenerates many LF->CRLF warnings [2]:\n\nfor i in `git diff --name-only`; do\n      echo $i\n      sed 's/0x0D//' < $i > foo\n      mv foo $i\n      git add $i\ndone\n\n>> Would you accept a patch explaining how \"git reset --hard\" doesn't\n>> actually rebuild the index from scratch,...\n>\n> Absolutely.\n\nI'll try to get to it, given the $dayjob / $significant_other constraints.\n\n- Eric\n\n[1] I've had cases where for whatever reasons a \"git read-tree HEAD\"\n     seemed to be required, but I don't have the recipe yet.\n[2] Which can be abolished by wrapping it in autocrlf=false\n     before and autocrlf=true after\n"}]}