{"thread":{"id":"43804","subject":"[ANNOUNCE] Git for Windows 2.9.3","startedAt":"2016-08-13T10:22:26Z","lastAt":"2016-08-25T13:58:02Z","messageCount":24,"participants":["Johannes Schindelin","Junio C Hamano","Duy Nguyen","Michael J Gruber","Dakota Hawkins","Philip Oakley","Torsten Bögershausen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298961","messageId":"alpine.DEB.2.20.1608131214070.4924@virtualbox","threadId":"43804","inReplyTo":null,"subject":"[ANNOUNCE] Git for Windows 2.9.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-13T10:14:15Z","receivedAt":"2016-08-13T10:22:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Dear Git users,\n\nIt is my pleasure to announce that Git for Windows 2.9.3 is available from:\n\n\thttps://git-for-windows.github.io/\n\nChanges since Git for Windows v2.9.2 (July 16th 2016)\n\nNew Features\n\n • Comes with Git 2.9.3.\n • Updated Git Credential Manager to version 1.6.0.\n • Includes support for git status --porcelain=v2.\n • Avoids evaluating unnecessary patch IDs when determining which\n commits do not need to be rebased because they are already\n upstream.\n • Sports a new --smudge option for git cat-file that lets it pass\n blob contents through smudge filters configured for the specified\n path.\n\nBug Fixes\n\n • When offering to Launch Git Bash after the installation, it now\n launches in the home directory, consistent with the Git Bash Start\n Menu entry.\n • When ~/.gitconfig sets core.hideDotFiles=false, git init respects\n that again.\n\nFilename | SHA-256\n-------- | -------\nGit-2.9.3-64-bit.exe | 1a642cf2914e18fa868b1ed2c6d1df4a46ba8ef30355fd1965850895a658e024\nGit-2.9.3-32-bit.exe | d6b4a19536ad408018688f1242ab0d1f5dc5544109662bfddf915f685eba58a9\nPortableGit-2.9.3-64-bit.7z.exe | 3423ea5c7e025a67903e05d1493680d6d5d6666429a9c400cc9e33beea5adb1b\nPortableGit-2.9.3-32-bit.7z.exe | cd142cbb124d7c3e3c3bf144785e57573afd2fc9c043447b7f5111ec044e6ced\nMinGit-2.9.3-64-bit.zip | 17e40cb149ce6a348c8e8bbe7f1c1fff00f82882f0e57f32d60ea5c26feeef98\nMinGit-2.9.3-32-bit.zip | 3c6515c09ccb7d1aa6620db51245c87f9836fbde5ee9af6c849b4cbd506f60e8\nGit-2.9.3-64-bit.tar.bz2 | 7b165d400c2bcc427881d502dd46cd442e512053d92cba8b3e46173c5028e427\nGit-2.9.3-32-bit.tar.bz2 | 00f265ddbbfedd25a8a0c38a33a6cb12761101a019f0c7f6189f07e771a522b7\n\nCiao,\nJohannes"},{"id":"298974","messageId":"xmqqshu8u0px.fsf@gitster.mtv.corp.google.com","threadId":"43804","inReplyTo":"alpine.DEB.2.20.1608131214070.4924@virtualbox","subject":"Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-13T15:50:50Z","receivedAt":"2016-08-13T15:51:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> New Features\n>\n> • Comes with Git 2.9.3.\n\nFor future reference, what time (in UTC) of the day is convenient\nfor you to see an upstream tarball?\n\n> • Sports a new --smudge option for git cat-file that lets it pass\n> blob contents through smudge filters configured for the specified\n> path.\n\nPerhaps we want to upstream this, together with a new \"--clean\"\noption for git hash-object?\n\nAnd after writing all of the above, I noticed that hash-object by\ndefault uses the clean machinery and that can be turned off by\ngiving the \"--no-filters\" option. The reason why the option is not\ncalled \"--no-clean\" is because it is not just about the clean filter\nbut is about using the entirety of convert_to_git() filter chain.\n\nWe probably should teach \"hash-objects\" to take \"--filters\" for\nconsistency.\n\nAnd then your \"git cat-file\" patch can be upstreamed with the option\nrenamed to (or with an additional synonym) \"--filters\", which would\nmake things consistent.\n\nThanks.\n\n"},{"id":"299547","messageId":"alpine.DEB.2.20.1608171507530.4924@virtualbox","threadId":"43804","inReplyTo":"xmqqshu8u0px.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-17T13:54:20Z","receivedAt":"2016-08-17T13:55:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Sat, 13 Aug 2016, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > New Features\n> >\n> > • Comes with Git 2.9.3.\n> \n> For future reference, what time (in UTC) of the day is convenient\n> for you to see an upstream tarball?\n\nHeh... I don't do tarballs anymore, I now use this newfangled tool to\nmanage source code... \"gyt\" or something like that, it is called.\n\n:-)\n\nGiven that between you and me there is currently a time zone difference of\n9h (except for four weeks, two in spring, when it is only 8h, and two in\nfall, when it is 10h), I believe we cannot find a time that is convenient\nfor both of us.\n\nBut I also think it is fine, when I discover a new upstream Git version in\nthe morning, I can spend all day on fixing any problems and on packaging\nthe result ;-)\n\n> > • Sports a new --smudge option for git cat-file that lets it pass\n> > blob contents through smudge filters configured for the specified\n> > path.\n> \n> Perhaps we want to upstream this, together with a new \"--clean\" option\n> for git hash-object?\n\nNo question about that. I just needed this in a hurry and short-circuited\nit into Git for Windows before submitting it upstream.\n\n> And after writing all of the above, I noticed that hash-object by\n> default uses the clean machinery and that can be turned off by giving\n> the \"--no-filters\" option. The reason why the option is not called\n> \"--no-clean\" is because it is not just about the clean filter but is\n> about using the entirety of convert_to_git() filter chain.\n\nRight, as is the --smudge option (it is about the entirety of\nconvert_to_worktree()).\n\n> We probably should teach \"hash-objects\" to take \"--filters\" for\n> consistency.\n\nI actually thought about that, too. Which was one of the reasons I did not\nsubmit the patch to the Git mailing list first, as I expect several\niterations to be necessary to get everything into `master`.\n\n> And then your \"git cat-file\" patch can be upstreamed with the option\n> renamed to (or with an additional synonym) \"--filters\", which would make\n> things consistent.\n\nRight. I would like to ask for a `--smudge` synonym nevertheless, just\nbecause I already use this. On the other hand, it is early enough to tell\neverybody who knows about this feature to change their invocation (anybody\nwho would know about `--smudge` would be in that 1% of users that have\nread the release notes, so most likely would read the next release notes,\ntoo).\n\nCiao,\nDscho"},{"id":"299549","messageId":"xmqqeg5nbehc.fsf@gitster.mtv.corp.google.com","threadId":"43804","inReplyTo":"alpine.DEB.2.20.1608171507530.4924@virtualbox","subject":"Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-17T15:29:51Z","receivedAt":"2016-08-17T15:29:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> And then your \"git cat-file\" patch can be upstreamed with the option\n>> renamed to (or with an additional synonym) \"--filters\", which would make\n>> things consistent.\n>\n> Right. I would like to ask for a `--smudge` synonym nevertheless, just\n> because I already use this. On the other hand, it is early enough to tell\n> everybody who knows about this feature to change their invocation (anybody\n> who would know about `--smudge` would be in that 1% of users that have\n> read the release notes, so most likely would read the next release notes,\n> too).\n\nIt is OK if it were your private edition, but you end up hurting\nyour users if you need to redo the feature differently.\n\nThat's the price of your using open source and taking a short-cut.\nAdding a \"--smudge\" synonym is spreading the same hurt to outside\nyour fork. Let's see if we can avoid doing that. Perhaps mark that\n\"--smudge\" as experimental-and-subject-to-change and re-announce?\n\n"},{"id":"299597","messageId":"alpine.DEB.2.20.1608181022250.4924@virtualbox","threadId":"43804","inReplyTo":"xmqqeg5nbehc.fsf@gitster.mtv.corp.google.com","subject":"Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-18T08:37:20Z","receivedAt":"2016-08-18T08:38:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 17 Aug 2016, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> And then your \"git cat-file\" patch can be upstreamed with the option\n> >> renamed to (or with an additional synonym) \"--filters\", which would make\n> >> things consistent.\n> >\n> > Right. I would like to ask for a `--smudge` synonym nevertheless, just\n> > because I already use this. On the other hand, it is early enough to tell\n> > everybody who knows about this feature to change their invocation (anybody\n> > who would know about `--smudge` would be in that 1% of users that have\n> > read the release notes, so most likely would read the next release notes,\n> > too).\n> \n> It is OK if it were your private edition, but you end up hurting\n> your users if you need to redo the feature differently.\n\nUnfortunately, this is the situation of Git for Windows from its\nbeginning: there has not been a single time that Git for Windows could\nlive with unpatched upstream Git's source code.\n\nBusiness as usual, though.\n\n> That's the price of your using open source and taking a short-cut.\n> Adding a \"--smudge\" synonym is spreading the same hurt to outside\n> your fork. Let's see if we can avoid doing that. Perhaps mark that\n> \"--smudge\" as experimental-and-subject-to-change and re-announce?\n\nI do not think so.\n\nI have plenty of experience to deal with the problem caused by Git for\nWindows requiring plenty of patches on top of your Git versions. I can\neasily deal with this here problem, too.\n\nFYI there have been two very strong reasons why I did not go through the\nreview on the Git mailing list for the --smudge option: 1) I really needed\nthis quick, and last time I needed something quick, it did not exactly\nwork out, now, did it, and 2) as far as I am concerned, the most important\npart of developing patches is the practical testing, and this belief was\nreinforced by the core.hideDotFiles feature that was well-tested and\nwell-exercised through years, only to be broken by changes necessitated by\nthe review on the Git mailing list: despite the best efforts of both you\nand me, we managed to worsimprove the patches to a point where they may\nlook more elegant than before, but unfortunately are also less correct at\nthe same time.\n\nSo I learned my lesson: I will try better to get patches robust and stable\nby exercising them and developing them as needed (the --smudge feature,\nfor example, turned out to be only half of what I need, I developed more\npatches on that front), and I will be careful to avoid major modifications\nof my patches just to get things upstream. It is better to carry correct\npatches in Git for Windows than to upstream incorrect revisions of them.\n\nIdeally, all of the patches I carry in Git for Windows would make it into\ngit.git eventually, of course. I fully support that. But not at the price\nof breakages.\n\nCiao,\nDscho\n"},{"id":"299851","messageId":"CACsJy8A3tkMY-iLPCDj9sqB4HpAK_cxsUu5Z7fsGcCQEORyxUg@mail.gmail.com","threadId":"43804","inReplyTo":"alpine.DEB.2.20.1608181022250.4924@virtualbox","subject":"Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-08-22T14:04:53Z","receivedAt":"2016-08-22T14:05:45Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin\n wrote:\n> Hi Junio,\n>\n> On Wed, 17 Aug 2016, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>>\n>> >> And then your \"git cat-file\" patch can be upstreamed with the option\n>> >> renamed to (or with an additional synonym) \"--filters\", which would make\n>> >> things consistent.\n>> >\n>> > Right. I would like to ask for a `--smudge` synonym nevertheless, just\n>> > because I already use this. On the other hand, it is early enough to tell\n>> > everybody who knows about this feature to change their invocation (anybody\n>> > who would know about `--smudge` would be in that 1% of users that have\n>> > read the release notes, so most likely would read the next release notes,\n>> > too).\n>>\n>> It is OK if it were your private edition, but you end up hurting\n>> your users if you need to redo the feature differently.\n>\n> Unfortunately, this is the situation of Git for Windows from its\n> beginning: there has not been a single time that Git for Windows could\n> live with unpatched upstream Git's source code.\n>\n> Business as usual, though.\n\nBug fixes is one thing, features is completely different. Should we\njust acknowledge git-for-windows as a long-living fork and rename it\nto something else? Because if somebody comes here with a \"git\" problem\non Windows, I would look at git.git source code, not gfw. I'd rather\nrecognize it a special fork (by name) right away and ignore. You could\nhave the same policy distros have: all bugs go to distros (i.e. gfw),\nsome bugs may be forwarded upstream (git.git).\n-- \nDuy\n"},{"id":"299930","messageId":"alpine.DEB.2.20.1608231553030.4924@virtualbox","threadId":"43804","inReplyTo":"CACsJy8A3tkMY-iLPCDj9sqB4HpAK_cxsUu5Z7fsGcCQEORyxUg@mail.gmail.com","subject":"Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-23T13:54:01Z","receivedAt":"2016-08-23T13:54:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Duy,\n\nOn Mon, 22 Aug 2016, Duy Nguyen wrote:\n\n> On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin\n> wrote:\n> > Hi Junio,\n> >\n> > On Wed, 17 Aug 2016, Junio C Hamano wrote:\n> >\n> >> Johannes Schindelin writes:\n> >>\n> >> >> And then your \"git cat-file\" patch can be upstreamed with the option\n> >> >> renamed to (or with an additional synonym) \"--filters\", which would make\n> >> >> things consistent.\n> >> >\n> >> > Right. I would like to ask for a `--smudge` synonym nevertheless, just\n> >> > because I already use this. On the other hand, it is early enough to tell\n> >> > everybody who knows about this feature to change their invocation (anybody\n> >> > who would know about `--smudge` would be in that 1% of users that have\n> >> > read the release notes, so most likely would read the next release notes,\n> >> > too).\n> >>\n> >> It is OK if it were your private edition, but you end up hurting\n> >> your users if you need to redo the feature differently.\n> >\n> > Unfortunately, this is the situation of Git for Windows from its\n> > beginning: there has not been a single time that Git for Windows could\n> > live with unpatched upstream Git's source code.\n> >\n> > Business as usual, though.\n> \n> Bug fixes is one thing, features is completely different.\n\nOh? Completely?\n\nSo the core.hideDotFiles feature should have forced me to rename Git for\nWindows to, say, DschoGit on Windows?\n\nLet's just stop here. This is getting too silly.\n\nCiao,\nDscho\n"},{"id":"299932","messageId":"2a6d2230-90ce-0f54-c7ae-a5aa595a2f73@drmicha.warpmail.net","threadId":"43804","inReplyTo":"alpine.DEB.2.20.1608231553030.4924@virtualbox","subject":"Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2016-08-23T14:41:07Z","receivedAt":"2016-08-23T14:48:21Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Schindelin venit, vidit, dixit 23.08.2016 15:54:\n> Hi Duy,\n> \n> On Mon, 22 Aug 2016, Duy Nguyen wrote:\n> \n>> On Thu, Aug 18, 2016 at 3:37 PM, Johannes Schindelin\n>> wrote:\n>>> Hi Junio,\n>>>\n>>> On Wed, 17 Aug 2016, Junio C Hamano wrote:\n>>>\n>>>> Johannes Schindelin writes:\n>>>>\n>>>>>> And then your \"git cat-file\" patch can be upstreamed with the option\n>>>>>> renamed to (or with an additional synonym) \"--filters\", which would make\n>>>>>> things consistent.\n>>>>>\n>>>>> Right. I would like to ask for a `--smudge` synonym nevertheless, just\n>>>>> because I already use this. On the other hand, it is early enough to tell\n>>>>> everybody who knows about this feature to change their invocation (anybody\n>>>>> who would know about `--smudge` would be in that 1% of users that have\n>>>>> read the release notes, so most likely would read the next release notes,\n>>>>> too).\n>>>>\n>>>> It is OK if it were your private edition, but you end up hurting\n>>>> your users if you need to redo the feature differently.\n>>>\n>>> Unfortunately, this is the situation of Git for Windows from its\n>>> beginning: there has not been a single time that Git for Windows could\n>>> live with unpatched upstream Git's source code.\n>>>\n>>> Business as usual, though.\n>>\n>> Bug fixes is one thing, features is completely different.\n> \n> Oh? Completely?\n> \n> So the core.hideDotFiles feature should have forced me to rename Git for\n> Windows to, say, DschoGit on Windows?\n> \n> Let's just stop here. This is getting too silly.\n\nI see more truth than silliness in Duy's suggestion. Maybe you want to\nre-read what you wrote to trigger his response, and consider adjusting\nyour attitude (\"I want this now so I'll release it in Git4Win\") rather\nthan the downstream name.\n\nMichael\n\n"},{"id":"299934","messageId":"alpine.DEB.2.20.1608231736180.4924@virtualbox","threadId":"43804","inReplyTo":"2a6d2230-90ce-0f54-c7ae-a5aa595a2f73@drmicha.warpmail.net","subject":"Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-23T15:37:44Z","receivedAt":"2016-08-23T15:39:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Michael,\n\nOn Tue, 23 Aug 2016, Michael J Gruber wrote:\n\n> Maybe you want to re-read what you wrote to trigger his response, and\n> consider adjusting your attitude (\"I want this now so I'll release it in\n> Git4Win\") rather than the downstream name.\n\nI am working *very* hard on improving the user experience of Git for\nWindows. And yes, sometimes I have to include something in Git for Windows\nversions that upstream Git does not include in the corresponding version\nnumber.\n\nI am really at a loss why you see fit to attack me about that.\n\nCiao,\nDscho\n"},{"id":"299958","messageId":"alpine.DEB.2.20.1608231758260.4924@virtualbox","threadId":"43804","inReplyTo":"alpine.DEB.2.20.1608231736180.4924@virtualbox","subject":"Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-23T16:05:32Z","receivedAt":"2016-08-23T16:36:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Michael,\n\nOn Tue, 23 Aug 2016, Johannes Schindelin wrote:\n\n> On Tue, 23 Aug 2016, Michael J Gruber wrote:\n> \n> > Maybe you want to re-read what you wrote to trigger his response, and\n> > consider adjusting your attitude (\"I want this now so I'll release it in\n> > Git4Win\") rather than the downstream name.\n> \n> I am working *very* hard on improving the user experience of Git for\n> Windows. And yes, sometimes I have to include something in Git for Windows\n> versions that upstream Git does not include in the corresponding version\n> number.\n> \n> I am really at a loss why you see fit to attack me about that.\n\nIn case it is not crystal-clear, let me clarify one very important point.\nIt seems that some people mistake the work I do for something I do on a\nwhim. This is not so.\n\nThe patch series that triggered this entire unfortunate discussion\nintroduced the --smudge option, which I have subsequently renamed to\n--filters and submitted as a patch series to the Git project.\n\nSo it is an altogether unfair misrepresentation to state that I introduce\nfeatures that deviate so much from upstream Git as to require a new name.\n\nThe feature in question is also highly unlikely to be used as much by\nnon-Windows users as by Windows users due to the unfortunate choice of the\ndefault setting for core.autocrlf. Basically, Windows users have to use\nthose --filters all the time, and in many cases, git cat-file --batch\nwithout --filters is simply useless. This is nothing, say, Linux users\nwould care about, of course, but Windows folks like me care a great deal\nabout it.\n\nIt is this need that literally guarantees that I will get more useful\nfeedback from Windows users about this feature (and in this context I mean\napplication developers) than from Linux or MacOSX users. And as a matter\nof fact, I got exactly that: great feedback. This feedback resulted in the\naddition of the --path option, and of the work I did on making --filters\ncompatible with the --batch mode.\n\nSo I take great exception at this criticism. I think these comments were\nnot really thought through, and I also would consider this discussion in\nand of itself (\"is Git for Windows really Git? Should it not be renamed,\ndespite Dscho's best efforts to get them in sync?\") to be much more\nharmful than any feature I introduced into Git for Windows before trying\nto get it integrated into upstream Git.\n\nThank you very much for your attention,\nDscho\n"},{"id":"299981","messageId":"xmqqzio3uw31.fsf@gitster.mtv.corp.google.com","threadId":"43804","inReplyTo":"alpine.DEB.2.20.1608231758260.4924@virtualbox","subject":"Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-23T19:25:06Z","receivedAt":"2016-08-23T19:30:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> In case it is not crystal-clear, let me clarify one very important point.\n> It seems that some people mistake the work I do for something I do on a\n> whim. This is not so.\n>\n> The patch series that triggered this entire unfortunate discussion\n> introduced the --smudge option, which I have subsequently renamed to\n> --filters and submitted as a patch series to the Git project.\n\nAs the \"--filters\" is meant as a new feature, it will not land on\nthe maintenance track. It is very likely that it won't be in 2.10,\nso it won't appear in 2.10.x maintenance track, either.\n\nI do not agree with Duy that the \"port to Windows\" needs a separate\ndistinct name, though. Having said that, aside from the issue of\nhandling of bugreports has been already meantioned, which mostly\ncosts for Git developers, whatever new feature you unleash ahead of\nupstream to your Windows port has cost to your end-users. Its\nimplementation or its external interface may have to change when you\nupstream the new feature that has already been in the field, and\nyour end-users would have to adjust their scripts and/or muscle\nmemory.\n\nOne way to avoid that risk may be to release the new feature as\n\"experimental-and-subject-to-change\", so that interested users on\nWindows can actually try it out to see if the feature itself\n(whatever its interface to them is) makes sense, and you can gauge\nthe value of upstreaming it, while cautioning these early adopters\nthat it has not fully been through the usual review process and may\nhave to change while becoming part of the official release. This is\nno different from various \"experimental features\" we unleash to the\nwild, either via 'master' or keeping it in 'next' (we tend to do\nmore of the latter, marking \"see if anybody screams\").\n\n\n\n"},{"id":"299991","messageId":"xmqqa8g3uppx.fsf@gitster.mtv.corp.google.com","threadId":"43804","inReplyTo":"xmqqzio3uw31.fsf@gitster.mtv.corp.google.com","subject":"Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-23T21:42:34Z","receivedAt":"2016-08-23T21:43:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> One way to avoid that risk may be to release the new feature as\n> \"experimental-and-subject-to-change\", so that interested users on\n> Windows can actually try it out to see if the feature itself\n> (whatever its interface to them is) makes sense, and you can gauge\n> the value of upstreaming it, while cautioning these early adopters\n> that it has not fully been through the usual review process and may\n> have to change while becoming part of the official release. This is\n> no different from various \"experimental features\" we unleash to the\n> wild, either via 'master' or keeping it in 'next' (we tend to do\n> more of the latter, marking \"see if anybody screams\").\n\nIn case it was not clear, I am _not_ saying that the port to Windows\nmust not ship with any feature that is not yet in the upstream (the\nsame goes for a port to Macs, where it may want to do more about\ndealing with Unicode \"normalization\" gotchas). The differences in\nplatforms make it more likely that needs for certain things are felt\nearlier and more strongly on a particular platform, and shipping a\nnew thing as an experimental feature to end-users may be the most\neffective way to come up with the best approach to help the users.\n\n"},{"id":"300018","messageId":"CAG0BQXmmW_0n4OMQVsVQ5+OKbNVpgXmXeExFUOXqY8nH=sg3Jw@mail.gmail.com","threadId":"43804","inReplyTo":"xmqqa8g3uppx.fsf@gitster.mtv.corp.google.com","subject":"Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Dakota Hawkins","fromEmail":"dakotahawkins@gmail.com","sentAt":"2016-08-24T01:04:26Z","receivedAt":"2016-08-24T01:04:47Z","isPatch":false,"sender":{"key":"dakotahawkins@gmail.com","avatar":"https://gravatar.com/avatar/6283c977565cfcecb284e62d5713a91a6a8df0a3b06f27439edaab4220ae143d?d=mp&s=160"},"body":"On Tue, Aug 23, 2016 at 5:42 PM, Junio C Hamano wrote:\n>\n> Junio C Hamano writes:\n>\n> > One way to avoid that risk may be to release the new feature as\n> > \"experimental-and-subject-to-change\", so that interested users on\n> > Windows can actually try it out to see if the feature itself\n> > (whatever its interface to them is) makes sense, and you can gauge\n> > the value of upstreaming it, while cautioning these early adopters\n> > that it has not fully been through the usual review process and may\n> > have to change while becoming part of the official release. This is\n> > no different from various \"experimental features\" we unleash to the\n> > wild, either via 'master' or keeping it in 'next' (we tend to do\n> > more of the latter, marking \"see if anybody screams\").\n>\n> In case it was not clear, I am _not_ saying that the port to Windows\n> must not ship with any feature that is not yet in the upstream (the\n> same goes for a port to Macs, where it may want to do more about\n> dealing with Unicode \"normalization\" gotchas). The differences in\n> platforms make it more likely that needs for certain things are felt\n> earlier and more strongly on a particular platform, and shipping a\n> new thing as an experimental feature to end-users may be the most\n> effective way to come up with the best approach to help the users.\n\nWhat is the practical difference between what happened and releasing a\nfeature as \"experimental-and-subject-to-change\"?\n\nI use GFW almost exclusively, but I pretty much always consult the\nupstream documentation anyway (because I find it easier).\n\nIt doesn't seem likely that many users who weren't in dire need of\nthis feature will even realize/remember it exists, so it's hard for me\nto conclude that anybody will really be harmed by this particular\n(temporary?) discontinuity.\n\nAt any rate it doesn't seem like you guys are going to persuade one\nanother and from the outside looking in it seems like this argument is\nmore ideological than technical, which makes it seem like it should\nprobably embarrass all involved because of its length and publicity.\nBut maybe I'm wrong, in which case I'm here to embarrass myself.\n\n-Dakota\n"},{"id":"300019","messageId":"xmqqbn0iu50a.fsf@gitster.mtv.corp.google.com","threadId":"43804","inReplyTo":"alpine.DEB.2.20.1608231758260.4924@virtualbox","subject":"Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-24T05:09:57Z","receivedAt":"2016-08-24T05:10:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> The feature in question is also highly unlikely to be used as much by\n> non-Windows users as by Windows users due to the unfortunate choice of the\n> default setting for core.autocrlf.\n\nMy vague recollection from some years ago was that even among those\nwho were active in msysGit development there were people who\nadvocated for straight-thru and others who wanted core.autocrlf as\nthe default, but I do not know the current state of the affairs.\n\nIn any case, in the ideal future, I would imagine that we would want\nto have \"cat-file blob\" to enable \"--filters\" by default; that would\nmake cat-file and hash-objects a pair of symmetric operations.\n\nThat certainly will not happen within 2.x timeframe, and the new\n\"cat-file --filter\" feature can appear in 2.11 at the earliest, but\nI think by that time (or with a few more cycles) we may have a\nhandful other improvements that are backward incompatible lined up\nto urge us to think about bumping the version number to 3.0. I\nrecall writing \"Will keep in next to see if anybody screams\" a few\ntimes already, and they are all good excuses to invite a version\nbump.\n\nTo prepare for that future, we would probably want to start updating\nin-tree scripts (including the tests) so that they call \"cat-file\n--no-filter blob\" whereever they currently say \"cat-file blob\" in or\nsoon after 2.11. Of course, if some of them currently pipe\n\"cat-file blob\" output to munge it to produce what --filters would\nhave done (I didn't check), we would want to rewrite them to use the\nnew feature \"cat-file --filter blob\" when we do so. In short, there\nwon't be any \"cat-file blob\" call that does not have either --filters\nor --no-filters, except the ones we write specifically to check the\nupdated default behaviour when that happens.\n\nWould that sound like a good longer-term plan?\n"},{"id":"300054","messageId":"alpine.DEB.2.20.1608241735520.4924@virtualbox","threadId":"43804","inReplyTo":"xmqqzio3uw31.fsf@gitster.mtv.corp.google.com","subject":"Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-24T15:39:43Z","receivedAt":"2016-08-24T15:40:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Tue, 23 Aug 2016, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > In case it is not crystal-clear, let me clarify one very important point.\n> > It seems that some people mistake the work I do for something I do on a\n> > whim. This is not so.\n> >\n> > The patch series that triggered this entire unfortunate discussion\n> > introduced the --smudge option, which I have subsequently renamed to\n> > --filters and submitted as a patch series to the Git project.\n> \n> As the \"--filters\" is meant as a new feature, it will not land on\n> the maintenance track. It is very likely that it won't be in 2.10,\n> so it won't appear in 2.10.x maintenance track, either.\n\nRight. Which is even more a reason for me to decouple this feature from\nnon-Windows Git.\n\n> [...] whatever new feature you unleash ahead of upstream to your Windows\n> port has cost to your end-users. Its implementation or its external\n> interface may have to change when you upstream the new feature that has\n> already been in the field, and your end-users would have to adjust their\n> scripts and/or muscle memory.\n\nThis is nothing new. As I said earlier, I have plenty of experience with\nthis. Including the experience of worsimproving a feature that has been\nbattle-tested for years, only to be broken in the process to appease\nreviewers on the Git mailing list.\n\nI talk about the core.hideDotFiles feature, of course, which in the\nprocess of being integrated into core Git lost its ability to respect the\nsetting to be \"false\".\n\nGit for Windows has a work-around already, of course, it's just ugly, so I\nam hesitating to \"upstream it\" yet.\n\nAs I said. All of this is old hat. Git for Windows has been, and probably\nwill be for a long time to come, diverging from upstream Git. This is not\nsomething I wanted, or worked toward. It's just reality that happened and\nI have to deal with it and there is nothing to see here, please move on.\n\nCiao,\nDscho\n"},{"id":"300056","messageId":"alpine.DEB.2.20.1608241740320.4924@virtualbox","threadId":"43804","inReplyTo":"CAG0BQXmmW_0n4OMQVsVQ5+OKbNVpgXmXeExFUOXqY8nH=sg3Jw@mail.gmail.com","subject":"Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-24T15:41:50Z","receivedAt":"2016-08-24T15:42:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Dakota,\n\nOn Tue, 23 Aug 2016, Dakota Hawkins wrote:\n\n> I use GFW almost exclusively, but I pretty much always consult the\n> upstream documentation anyway (because I find it easier).\n\nOh... I thought that typing \"git help git-commit\" opening a nice HTML page\nin your favorite browser was good enough.\n\nDo you have any suggestion how to improve the user experience?\n\nThanks,\nJohannes\n"},{"id":"300059","messageId":"alpine.DEB.2.20.1608241743460.4924@virtualbox","threadId":"43804","inReplyTo":"xmqqbn0iu50a.fsf@gitster.mtv.corp.google.com","subject":"core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-24T15:48:40Z","receivedAt":"2016-08-24T15:49:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Tue, 23 Aug 2016, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > The feature in question is also highly unlikely to be used as much by\n> > non-Windows users as by Windows users due to the unfortunate choice of the\n> > default setting for core.autocrlf.\n> \n> My vague recollection from some years ago was that even among those\n> who were active in msysGit development there were people who\n> advocated for straight-thru and others who wanted core.autocrlf as\n> the default, but I do not know the current state of the affairs.\n\nI remember this very non-vaguely, for I was one of the people advocating\nstraight-through. I basically was shot down by people using Windows more\nregularly than I did.\n\nIn any case, now is not the time to lament about this.\n\n> In any case, in the ideal future, I would imagine that we would want\n> to have \"cat-file blob\" to enable \"--filters\" by default; that would\n> make cat-file and hash-objects a pair of symmetric operations.\n\nI would advocate against that. It is not like the terms \"hash-object\" and\n\"cat-file\" even *look* like they are opposites.\n\nThe main problem you face with making --filters the default is that it is\na possibly costly switch. Too costly in my opinion, just think of git-lfs.\n\n> That certainly will not happen within 2.x timeframe, and the new\n> \"cat-file --filter\" feature can appear in 2.11 at the earliest, but\n\ns/--filter/--filters/\n\n> I think by that time (or with a few more cycles) we may have a\n> handful other improvements that are backward incompatible lined up\n> to urge us to think about bumping the version number to 3.0. I\n> recall writing \"Will keep in next to see if anybody screams\" a few\n> times already, and they are all good excuses to invite a version\n> bump.\n> \n> To prepare for that future, we would probably want to start updating\n> in-tree scripts (including the tests) so that they call \"cat-file\n> --no-filter blob\" whereever they currently say \"cat-file blob\" in or\n\ns/--no-filter/--no-filters/\n\n> soon after 2.11. Of course, if some of them currently pipe\n> \"cat-file blob\" output to munge it to produce what --filters would\n> have done (I didn't check), we would want to rewrite them to use the\n> new feature \"cat-file --filter blob\" when we do so. In short, there\n\ns/--filter/--filters/\n\n> won't be any \"cat-file blob\" call that does not have either --filters\n> or --no-filters, except the ones we write specifically to check the\n> updated default behaviour when that happens.\n> \n> Would that sound like a good longer-term plan?\n\nApart from my objecting against changing the default of cat-file, it sure\nsounds like a good long-term plan ;-)\n\nCiao,\nDscho\n"},{"id":"300071","messageId":"CAG0BQXmovWAjn8sE=CFGMXguRpEqU3xUbF03aSEN4OLxNc9oZg@mail.gmail.com","threadId":"43804","inReplyTo":"alpine.DEB.2.20.1608241740320.4924@virtualbox","subject":"Re: Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Dakota Hawkins","fromEmail":"dakotahawkins@gmail.com","sentAt":"2016-08-24T16:06:59Z","receivedAt":"2016-08-24T16:15:17Z","isPatch":false,"sender":{"key":"dakotahawkins@gmail.com","avatar":"https://gravatar.com/avatar/6283c977565cfcecb284e62d5713a91a6a8df0a3b06f27439edaab4220ae143d?d=mp&s=160"},"body":"On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin\n wrote:\n> Hi Dakota,\n>\n> On Tue, 23 Aug 2016, Dakota Hawkins wrote:\n>\n>> I use GFW almost exclusively, but I pretty much always consult the\n>> upstream documentation anyway (because I find it easier).\n>\n> Oh... I thought that typing \"git help git-commit\" opening a nice HTML page\n> in your favorite browser was good enough.\n>\n> Do you have any suggestion how to improve the user experience?\n\nJust a small one, and that's that I'd prefer the option to have help\ndisplay in my terminal (that option might exist and I don't know how\nto turn it on). That would be very convenient for me.\n\nOpening a nice HTML page is probably nice for a lot of users. What\nfrustrates me about it is that I don't know which browser window on\nwhich monitor (of 3) it's going to open in, so it's a context-switch\nto a different window somewhere that I don't have much control over.\n\nThe thing I find easier about using the upstream documentation is just\nthat I can pick the browser window I want it to come up in, and it's\nusually faster enough for me to just google \"git-whatever\" or\nre-purpose an open doc tab. I don't prefer the _content_ of the\nupstream documentation, it's just less frustrating for me to use, if\nthat makes sense.\n\n-Dakota\n"},{"id":"300078","messageId":"xmqq37luru7z.fsf@gitster.mtv.corp.google.com","threadId":"43804","inReplyTo":"alpine.DEB.2.20.1608241743460.4924@virtualbox","subject":"Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-24T16:45:52Z","receivedAt":"2016-08-24T16:46:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> In any case, in the ideal future, I would imagine that we would want\n>> to have \"cat-file blob\" to enable \"--filters\" by default; that would\n>> make cat-file and hash-objects a pair of symmetric operations.\n>\n> I would advocate against that. It is not like the terms \"hash-object\" and\n> \"cat-file\" even *look* like they are opposites.\n\nI do not quite understand your objection.\n\nhash-object is \"I have data somewhere on the filesystem, and I want\nto store it in the object store even though I am not ready to add it\nto the index yet (or I may not even add it to the index ever), just\nto make it available to Git tools\". cat-file is \"I have data in the\nobject store, I want to make it available to my other tools that\nunderstand data stored on the filesystem.\"\n\nWhen we taught \"--no-filters\" to \"hash-object\" back in 2008, we\nshould have realized that \"cat-file :path >path\" would want to be a\nway to do \"checkout path\" (with \"--no-filters\" option to allow us to\ninspect the \"canonical version\"), but we didn't.\n\nYes, correcting ancient mistakes is costly. Such is life.\n\n"},{"id":"300129","messageId":"99BC268995014F88A25852349769FD02@PhilipOakley","threadId":"43804","inReplyTo":"CAG0BQXmovWAjn8sE=CFGMXguRpEqU3xUbF03aSEN4OLxNc9oZg@mail.gmail.com","subject":"Re: Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-24T23:28:14Z","receivedAt":"2016-08-24T23:28:29Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Dakota Hawkins\" \n> On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin\n> wrote:\n>> Hi Dakota,\n>>\n>> On Tue, 23 Aug 2016, Dakota Hawkins wrote:\n>>\n>>> I use GFW almost exclusively, but I pretty much always consult the\n>>> upstream documentation anyway (because I find it easier).\n>>\n>> Oh... I thought that typing \"git help git-commit\" opening a nice HTML \n>> page\n>> in your favorite browser was good enough.\n>>\n>> Do you have any suggestion how to improve the user experience?\n>\n> Just a small one, and that's that I'd prefer the option to have help\n> display in my terminal (that option might exist and I don't know how\n> to turn it on). That would be very convenient for me.\n>\n> Opening a nice HTML page is probably nice for a lot of users. What\n> frustrates me about it is that I don't know which browser window on\n> which monitor (of 3) it's going to open in, so it's a context-switch\n> to a different window somewhere that I don't have much control over.\n>\n> The thing I find easier about using the upstream documentation is just\n> that I can pick the browser window I want it to come up in, and it's\n> usually faster enough for me to just google \"git-whatever\" or\n> re-purpose an open doc tab. I don't prefer the _content_ of the\n> upstream documentation, it's just less frustrating for me to use, if\n> that makes sense.\n>\nIf you would like to use the man pages, then one option is to install the \nSDK, which then allows you to install the man package, (setting the manpath \nas required) to allow your choice of viewer. You may need to set the minnty \nconfig BoldAsFont=yes if you want the bold for the headings in the man \npages.\n\nWith the SDK you can also create a personal release version of GfW that \nincludes the man viewer if you like.\n--\nPhilip\n\n"},{"id":"300147","messageId":"alpine.DEB.2.20.1608251339510.4924@virtualbox","threadId":"43804","inReplyTo":"CAG0BQXmovWAjn8sE=CFGMXguRpEqU3xUbF03aSEN4OLxNc9oZg@mail.gmail.com","subject":"Re: Git for Windows documentation, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-25T11:42:25Z","receivedAt":"2016-08-25T11:43:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Dakota,\n\nOn Wed, 24 Aug 2016, Dakota Hawkins wrote:\n\n> On Wed, Aug 24, 2016 at 11:41 AM, Johannes Schindelin\n> wrote:\n> >\n> > On Tue, 23 Aug 2016, Dakota Hawkins wrote:\n> >\n> >> I use GFW almost exclusively, but I pretty much always consult the\n> >> upstream documentation anyway (because I find it easier).\n> >\n> > Oh... I thought that typing \"git help git-commit\" opening a nice HTML\n> > page in your favorite browser was good enough.\n> >\n> > Do you have any suggestion how to improve the user experience?\n> \n> Just a small one, and that's that I'd prefer the option to have help\n> display in my terminal (that option might exist and I don't know how to\n> turn it on). That would be very convenient for me.\n\nAh, okay... The reason why this is not that easy is: we ship with HTML\ndocumentation (and skip `man` altogether, also to conserve space in the\nalready large installer: it is ~30MB, which might seem acceptable to you\nuntil you are stuck in a country where the download is at 30-70 kB/s).\n\nSo I am afraid that the only solution in that case would be to install the\nGit for Windows SDK (https://git-for-windows.github.io/#download-sdk, as\npointed out by Philip).\n\nCiao,\nJohannes\n"},{"id":"300148","messageId":"alpine.DEB.2.20.1608251343300.4924@virtualbox","threadId":"43804","inReplyTo":"xmqq37luru7z.fsf@gitster.mtv.corp.google.com","subject":"Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-25T11:54:41Z","receivedAt":"2016-08-25T11:56:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 24 Aug 2016, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> In any case, in the ideal future, I would imagine that we would want\n> >> to have \"cat-file blob\" to enable \"--filters\" by default; that would\n> >> make cat-file and hash-objects a pair of symmetric operations.\n> >\n> > I would advocate against that. It is not like the terms \"hash-object\" and\n> > \"cat-file\" even *look* like they are opposites.\n> \n> I do not quite understand your objection.\n> \n> hash-object is \"I have data somewhere on the filesystem, and I want\n> to store it in the object store even though I am not ready to add it\n> to the index yet (or I may not even add it to the index ever), just\n> to make it available to Git tools\".\n\nThat is not how I read it. I read \"hash-object\" as: \"hash this object\".\nThere was not a thought in my mind that it would apply filters. Since that\nwas so clear in my mind, I failed to understand that you do not consider\nit a design mistake to turn on --filters by default in hash-object.\n\nI read \"cat-file\" just the same: concatenate files and print on the\nstandard output. Now, it is confusing enough that it does not concatenate\nfiles in unless in batch mode, and it would be even more confusing if it\nstarted to behave as if the user had called \"git checkout --dry-run\n -- \" (which does not exist, but for which I would\nunderstand the --filters default).\n\n> Yes, correcting ancient mistakes is costly. Such is life.\n\nI was not talking about the cost of correcting mistakes. Running --filters\nis potentially very costly. Just so you understand what I am talking\nabout: I have a report that says that checking out a sizeable worktree\nwith core.autocrlf=true is 58% slower than with core.autocrlf=false. That\nis horrible. And it is a cost that is entirely born by Windows users.\n\nIn short: I think letting hash-object default to --filters was a mistake,\nand doing the same for cat-file would be a mistake, too.\n\nCiao,\nDscho\n"},{"id":"300152","messageId":"8b3f92e5-0cac-ebb1-0f03-460ba3ad4d32@web.de","threadId":"43804","inReplyTo":"alpine.DEB.2.20.1608251343300.4924@virtualbox","subject":"Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2016-08-25T12:43:27Z","receivedAt":"2016-08-25T12:44:18Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"\n> I was not talking about the cost of correcting mistakes. Running --filters\n> is potentially very costly. Just so you understand what I am talking\n> about: I have a report that says that checking out a sizeable worktree\n> with core.autocrlf=true is 58% slower than with core.autocrlf=false. That\n> is horrible. []\n\nIs this a public repo ?\n\nOr is there a benchmark repo somewhere ?\n\n"},{"id":"300160","messageId":"alpine.DEB.2.20.1608251547510.4924@virtualbox","threadId":"43804","inReplyTo":"8b3f92e5-0cac-ebb1-0f03-460ba3ad4d32@web.de","subject":"Re: core.autocrlf, was Re: [git-for-windows] Re: [ANNOUNCE] Git for Windows 2.9.3","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-08-25T13:50:53Z","receivedAt":"2016-08-25T13:58:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Torsten,\n\nOn Thu, 25 Aug 2016, Torsten Bögershausen wrote:\n\n> > I was not talking about the cost of correcting mistakes. Running --filters\n> > is potentially very costly. Just so you understand what I am talking\n> > about: I have a report that says that checking out a sizeable worktree\n> > with core.autocrlf=true is 58% slower than with core.autocrlf=false. That\n> > is horrible. []\n> \n> Is this a public repo ?\n\nNo.\n\n> Or is there a benchmark repo somewhere ?\n\nUnfortunately not. The only information I have is that it contains\ngazillions of files and that most of that time was spent in figuring out\nwhether the files contain CR/LF, LF, or both.\n\nI hope to get back to some performance benchmarking soon. I have some\nexperimental code to generate Git repositories of a specific size, and I\nhope to be able to replicate the issues with that infrastructure.\n\nShould be fun.\n\nCiao,\nDscho"}]}