{"thread":{"id":"50150","subject":"git version 2.20.1.windows.1 throws file name too long in gitk","startedAt":"2019-01-04T02:21:28Z","lastAt":"2019-05-29T18:07:57Z","messageCount":10,"participants":["Bret Barkelew","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"366128","messageId":"CAGTkKag2sFy+Of=6uQeiGOQm0-NBrh9ixgzDoQXKR73+Ct3raQ@mail.gmail.com","threadId":"50150","inReplyTo":null,"subject":"git version 2.20.1.windows.1 throws file name too long in gitk","fromName":"Bret Barkelew","fromEmail":"bret@corthon.com","sentAt":"2019-01-04T02:21:14Z","receivedAt":"2019-01-04T02:21:28Z","isPatch":false,"sender":{"key":"bret@corthon.com","avatar":"https://gravatar.com/avatar/9a370be172af79638f919295074527b53afe3147b7df1251a45ae93d6498f376?d=mp&s=160"},"body":"When I open gitk in a particular repository under this version of Git\nfor Windows, I now get a dialog box that says \"Error: couldn't execute\n\"git\": file name too long\". I've noticed that the most pronounced\neffect is that I cannot see the file diffs (or sometimes the file name\nlist) for any of the commits. I don't know the exact repro, but I've\nnarrowed down the following things:\n\n- This does not happen with the same repo if I use a system that has\ngit 2.19.0.windows.1 on another machine.\n- This does not happen on my current machine in a freshly cloned repo.\nHowever, as soon as the remote updates with any changes on a given\nfetch/pull, the repo is put in a bad state permanently.\n\nI've pasted the output from gitk below...\n\ncouldn't execute \"git\": file name too long\ncouldn't execute \"git\": file name too long\n    while executing\n\"open $cmd r\"\n    (procedure \"getallcommits\" line 48)\n    invoked from within\n\"getallcommits\"\n    (procedure \"readcache\" line 80)\n    invoked from within\n\"readcache file827e200\"\n    (\"eval\" body line 1)\n    invoked from within\n\"eval $script\"\n    (procedure \"dorunq\" line 11)\n    invoked from within\n\"dorunq\"\n    (\"after\" script)\n\nHappy to gather whatever data needed.\nThanks!\n- Bret Barkelew\n"},{"id":"366130","messageId":"CAGTkKag-fTy3iZAKJxEnWD6_b_3pfuYvQQKBkLaeSL8wKM2sfg@mail.gmail.com","threadId":"50150","inReplyTo":"CAGyf7-HcncFOfmm5McEkOvCTkHNdePDSEQDZwEAK=z1bmC=QKw@mail.gmail.com","subject":"Re: git version 2.20.1.windows.1 throws file name too long in gitk","fromName":"Bret Barkelew","fromEmail":"bret@corthon.com","sentAt":"2019-01-04T03:38:04Z","receivedAt":"2019-01-04T03:39:32Z","isPatch":false,"sender":{"key":"bret@corthon.com","avatar":"https://gravatar.com/avatar/9a370be172af79638f919295074527b53afe3147b7df1251a45ae93d6498f376?d=mp&s=160"},"body":"They are the exact same path (with a different drive letter).\n\nAnother thing I've been able to confirm is I uninstalled git 2.20.1\nand installed 2.19.0 on the failing system, and the older version of\nGit works.\nI've also tried a suggested fix I saw elsewhere to enable long path\nnames in the Windows registry, which did not resolve the issue with\ngit 2.20.1.\n\nHappy to collect any additional data.\n- Bret\n\nOn Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:\n>\n> On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:\n>>\n>> When I open gitk in a particular repository under this version of Git\n>> for Windows, I now get a dialog box that says \"Error: couldn't execute\n>> \"git\": file name too long\". I've noticed that the most pronounced\n>> effect is that I cannot see the file diffs (or sometimes the file name\n>> list) for any of the commits. I don't know the exact repro, but I've\n>> narrowed down the following things:\n>>\n>> - This does not happen with the same repo if I use a system that has\n>> git 2.19.0.windows.1 on another machine.\n>> - This does not happen on my current machine in a freshly cloned repo.\n>\n>\n> How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?\n>\n> Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\\repo may not have issues, but the same repository cloned to C:\\Users\\Bryan\\Documents\\workspaces\\repo may.\n>\n>>\n>> However, as soon as the remote updates with any changes on a given\n>> fetch/pull, the repo is put in a bad state permanently.\n>>\n>> I've pasted the output from gitk below...\n>>\n>> couldn't execute \"git\": file name too long\n>> couldn't execute \"git\": file name too long\n>>     while executing\n>> \"open $cmd r\"\n>>     (procedure \"getallcommits\" line 48)\n>>     invoked from within\n>> \"getallcommits\"\n>>     (procedure \"readcache\" line 80)\n>>     invoked from within\n>> \"readcache file827e200\"\n>>     (\"eval\" body line 1)\n>>     invoked from within\n>> \"eval $script\"\n>>     (procedure \"dorunq\" line 11)\n>>     invoked from within\n>> \"dorunq\"\n>>     (\"after\" script)\n>>\n>> Happy to gather whatever data needed.\n>> Thanks!\n>> - Bret Barkelew\n"},{"id":"366436","messageId":"nycvar.QRO.7.76.6.1901091936420.41@tvgsbejvaqbjf.bet","threadId":"50150","inReplyTo":"CAGTkKag-fTy3iZAKJxEnWD6_b_3pfuYvQQKBkLaeSL8wKM2sfg@mail.gmail.com","subject":"Re: git version 2.20.1.windows.1 throws file name too long in gitk","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-01-09T18:39:11Z","receivedAt":"2019-01-09T18:39:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Bret,\n\n\nOn Thu, 3 Jan 2019, Bret Barkelew wrote:\n\n> They are the exact same path (with a different drive letter).\n\n[it's a bit hard to follow the thread if you top-post a reply to an\ninline-replied answer, maybe imitate the style of other mails in the\nfuture.]\n\n> Another thing I've been able to confirm is I uninstalled git 2.20.1\n> and installed 2.19.0 on the failing system, and the older version of\n> Git works.\n> I've also tried a suggested fix I saw elsewhere to enable long path\n> names in the Windows registry, which did not resolve the issue with\n> git 2.20.1.\n> \n> Happy to collect any additional data.\n\nPlease try the latest snapshot at\nhttps://wingit.blob.core.windows.net/files/index.html (I *think* the bug\nmight be fixed via\nhttps://github.com/git-for-windows/MINGW-packages/pull/32).\n\nCiao,\nJohannes\n\n> - Bret\n> \n> On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:\n> >\n> > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:\n> >>\n> >> When I open gitk in a particular repository under this version of Git\n> >> for Windows, I now get a dialog box that says \"Error: couldn't execute\n> >> \"git\": file name too long\". I've noticed that the most pronounced\n> >> effect is that I cannot see the file diffs (or sometimes the file name\n> >> list) for any of the commits. I don't know the exact repro, but I've\n> >> narrowed down the following things:\n> >>\n> >> - This does not happen with the same repo if I use a system that has\n> >> git 2.19.0.windows.1 on another machine.\n> >> - This does not happen on my current machine in a freshly cloned repo.\n> >\n> >\n> > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?\n> >\n> > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\\repo may not have issues, but the same repository cloned to C:\\Users\\Bryan\\Documents\\workspaces\\repo may.\n> >\n> >>\n> >> However, as soon as the remote updates with any changes on a given\n> >> fetch/pull, the repo is put in a bad state permanently.\n> >>\n> >> I've pasted the output from gitk below...\n> >>\n> >> couldn't execute \"git\": file name too long\n> >> couldn't execute \"git\": file name too long\n> >>     while executing\n> >> \"open $cmd r\"\n> >>     (procedure \"getallcommits\" line 48)\n> >>     invoked from within\n> >> \"getallcommits\"\n> >>     (procedure \"readcache\" line 80)\n> >>     invoked from within\n> >> \"readcache file827e200\"\n> >>     (\"eval\" body line 1)\n> >>     invoked from within\n> >> \"eval $script\"\n> >>     (procedure \"dorunq\" line 11)\n> >>     invoked from within\n> >> \"dorunq\"\n> >>     (\"after\" script)\n> >>\n> >> Happy to gather whatever data needed.\n> >> Thanks!\n> >> - Bret Barkelew\n> "},{"id":"366437","messageId":"CAGTkKajkW-U9mhh_GmTXmZQbnceEKX_BcMtOF4hOhEDZe2u9Bw@mail.gmail.com","threadId":"50150","inReplyTo":"nycvar.QRO.7.76.6.1901091936420.41@tvgsbejvaqbjf.bet","subject":"Re: git version 2.20.1.windows.1 throws file name too long in gitk","fromName":"Bret Barkelew","fromEmail":"bret@corthon.com","sentAt":"2019-01-09T18:48:56Z","receivedAt":"2019-01-09T18:49:09Z","isPatch":false,"sender":{"key":"bret@corthon.com","avatar":"https://gravatar.com/avatar/9a370be172af79638f919295074527b53afe3147b7df1251a45ae93d6498f376?d=mp&s=160"},"body":"Will try to reply in-line, when appropriate.\nThe latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still\nhas the issue.\n\n- Bret\n\n\nOn Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n>\n> Hi Bret,\n>\n>\n> On Thu, 3 Jan 2019, Bret Barkelew wrote:\n>\n> > They are the exact same path (with a different drive letter).\n>\n> [it's a bit hard to follow the thread if you top-post a reply to an\n> inline-replied answer, maybe imitate the style of other mails in the\n> future.]\n>\n> > Another thing I've been able to confirm is I uninstalled git 2.20.1\n> > and installed 2.19.0 on the failing system, and the older version of\n> > Git works.\n> > I've also tried a suggested fix I saw elsewhere to enable long path\n> > names in the Windows registry, which did not resolve the issue with\n> > git 2.20.1.\n> >\n> > Happy to collect any additional data.\n>\n> Please try the latest snapshot at\n> https://wingit.blob.core.windows.net/files/index.html (I *think* the bug\n> might be fixed via\n> https://github.com/git-for-windows/MINGW-packages/pull/32).\n>\n> Ciao,\n> Johannes\n>\n> > - Bret\n> >\n> > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:\n> > >\n> > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:\n> > >>\n> > >> When I open gitk in a particular repository under this version of Git\n> > >> for Windows, I now get a dialog box that says \"Error: couldn't execute\n> > >> \"git\": file name too long\". I've noticed that the most pronounced\n> > >> effect is that I cannot see the file diffs (or sometimes the file name\n> > >> list) for any of the commits. I don't know the exact repro, but I've\n> > >> narrowed down the following things:\n> > >>\n> > >> - This does not happen with the same repo if I use a system that has\n> > >> git 2.19.0.windows.1 on another machine.\n> > >> - This does not happen on my current machine in a freshly cloned repo.\n> > >\n> > >\n> > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?\n> > >\n> > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\\repo may not have issues, but the same repository cloned to C:\\Users\\Bryan\\Documents\\workspaces\\repo may.\n> > >\n> > >>\n> > >> However, as soon as the remote updates with any changes on a given\n> > >> fetch/pull, the repo is put in a bad state permanently.\n> > >>\n> > >> I've pasted the output from gitk below...\n> > >>\n> > >> couldn't execute \"git\": file name too long\n> > >> couldn't execute \"git\": file name too long\n> > >>     while executing\n> > >> \"open $cmd r\"\n> > >>     (procedure \"getallcommits\" line 48)\n> > >>     invoked from within\n> > >> \"getallcommits\"\n> > >>     (procedure \"readcache\" line 80)\n> > >>     invoked from within\n> > >> \"readcache file827e200\"\n> > >>     (\"eval\" body line 1)\n> > >>     invoked from within\n> > >> \"eval $script\"\n> > >>     (procedure \"dorunq\" line 11)\n> > >>     invoked from within\n> > >> \"dorunq\"\n> > >>     (\"after\" script)\n> > >>\n> > >> Happy to gather whatever data needed.\n> > >> Thanks!\n> > >> - Bret Barkelew\n> >\n"},{"id":"366503","messageId":"nycvar.QRO.7.76.6.1901101616100.41@tvgsbejvaqbjf.bet","threadId":"50150","inReplyTo":"CAGTkKajkW-U9mhh_GmTXmZQbnceEKX_BcMtOF4hOhEDZe2u9Bw@mail.gmail.com","subject":"Re: git version 2.20.1.windows.1 throws file name too long in gitk","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-01-10T15:19:53Z","receivedAt":"2019-01-10T15:20:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Bret,\n\nin that case, please try to find a way to trace the commands in a Tcl/Tk\nprogram (which gitk is) and see which command triggers the error.\n\nCiao,\nJohannes\n\n\nOn Wed, 9 Jan 2019, Bret Barkelew wrote:\n\n> Will try to reply in-line, when appropriate.\n> The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still\n> has the issue.\n> \n> - Bret\n> \n> \n> On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> >\n> > Hi Bret,\n> >\n> >\n> > On Thu, 3 Jan 2019, Bret Barkelew wrote:\n> >\n> > > They are the exact same path (with a different drive letter).\n> >\n> > [it's a bit hard to follow the thread if you top-post a reply to an\n> > inline-replied answer, maybe imitate the style of other mails in the\n> > future.]\n> >\n> > > Another thing I've been able to confirm is I uninstalled git 2.20.1\n> > > and installed 2.19.0 on the failing system, and the older version of\n> > > Git works.\n> > > I've also tried a suggested fix I saw elsewhere to enable long path\n> > > names in the Windows registry, which did not resolve the issue with\n> > > git 2.20.1.\n> > >\n> > > Happy to collect any additional data.\n> >\n> > Please try the latest snapshot at\n> > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug\n> > might be fixed via\n> > https://github.com/git-for-windows/MINGW-packages/pull/32).\n> >\n> > Ciao,\n> > Johannes\n> >\n> > > - Bret\n> > >\n> > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:\n> > > >\n> > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:\n> > > >>\n> > > >> When I open gitk in a particular repository under this version of Git\n> > > >> for Windows, I now get a dialog box that says \"Error: couldn't execute\n> > > >> \"git\": file name too long\". I've noticed that the most pronounced\n> > > >> effect is that I cannot see the file diffs (or sometimes the file name\n> > > >> list) for any of the commits. I don't know the exact repro, but I've\n> > > >> narrowed down the following things:\n> > > >>\n> > > >> - This does not happen with the same repo if I use a system that has\n> > > >> git 2.19.0.windows.1 on another machine.\n> > > >> - This does not happen on my current machine in a freshly cloned repo.\n> > > >\n> > > >\n> > > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?\n> > > >\n> > > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\\repo may not have issues, but the same repository cloned to C:\\Users\\Bryan\\Documents\\workspaces\\repo may.\n> > > >\n> > > >>\n> > > >> However, as soon as the remote updates with any changes on a given\n> > > >> fetch/pull, the repo is put in a bad state permanently.\n> > > >>\n> > > >> I've pasted the output from gitk below...\n> > > >>\n> > > >> couldn't execute \"git\": file name too long\n> > > >> couldn't execute \"git\": file name too long\n> > > >>     while executing\n> > > >> \"open $cmd r\"\n> > > >>     (procedure \"getallcommits\" line 48)\n> > > >>     invoked from within\n> > > >> \"getallcommits\"\n> > > >>     (procedure \"readcache\" line 80)\n> > > >>     invoked from within\n> > > >> \"readcache file827e200\"\n> > > >>     (\"eval\" body line 1)\n> > > >>     invoked from within\n> > > >> \"eval $script\"\n> > > >>     (procedure \"dorunq\" line 11)\n> > > >>     invoked from within\n> > > >> \"dorunq\"\n> > > >>     (\"after\" script)\n> > > >>\n> > > >> Happy to gather whatever data needed.\n> > > >> Thanks!\n> > > >> - Bret Barkelew\n> > >\n> "},{"id":"366518","messageId":"CAGTkKagTCw-EcMo3M1P3XVtjbTcm4HPjCWGZ1sM_NnJwH7v_hg@mail.gmail.com","threadId":"50150","inReplyTo":"nycvar.QRO.7.76.6.1901101616100.41@tvgsbejvaqbjf.bet","subject":"Re: git version 2.20.1.windows.1 throws file name too long in gitk","fromName":"Bret Barkelew","fromEmail":"bret@corthon.com","sentAt":"2019-01-10T18:55:35Z","receivedAt":"2019-01-10T18:55:49Z","isPatch":false,"sender":{"key":"bret@corthon.com","avatar":"https://gravatar.com/avatar/9a370be172af79638f919295074527b53afe3147b7df1251a45ae93d6498f376?d=mp&s=160"},"body":"On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n>\n> Hi Bret,\n>\n> in that case, please try to find a way to trace the commands in a Tcl/Tk\n> program (which gitk is) and see which command triggers the error.\n\nEr... that's a little out of my depth. I'll see if I can find time to learn.\nMeanwhile, is there any way to request better instrumentation for the\nerror dialog so this data could have been collected for me?\n\n>\n> Ciao,\n> Johannes\n>\n>\n> On Wed, 9 Jan 2019, Bret Barkelew wrote:\n>\n> > Will try to reply in-line, when appropriate.\n> > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still\n> > has the issue.\n> >\n> > - Bret\n> >\n> >\n> > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin\n> > <Johannes.Schindelin@gmx.de> wrote:\n> > >\n> > > Hi Bret,\n> > >\n> > >\n> > > On Thu, 3 Jan 2019, Bret Barkelew wrote:\n> > >\n> > > > They are the exact same path (with a different drive letter).\n> > >\n> > > [it's a bit hard to follow the thread if you top-post a reply to an\n> > > inline-replied answer, maybe imitate the style of other mails in the\n> > > future.]\n> > >\n> > > > Another thing I've been able to confirm is I uninstalled git 2.20.1\n> > > > and installed 2.19.0 on the failing system, and the older version of\n> > > > Git works.\n> > > > I've also tried a suggested fix I saw elsewhere to enable long path\n> > > > names in the Windows registry, which did not resolve the issue with\n> > > > git 2.20.1.\n> > > >\n> > > > Happy to collect any additional data.\n> > >\n> > > Please try the latest snapshot at\n> > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug\n> > > might be fixed via\n> > > https://github.com/git-for-windows/MINGW-packages/pull/32).\n> > >\n> > > Ciao,\n> > > Johannes\n> > >\n> > > > - Bret\n> > > >\n> > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:\n> > > > >\n> > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:\n> > > > >>\n> > > > >> When I open gitk in a particular repository under this version of Git\n> > > > >> for Windows, I now get a dialog box that says \"Error: couldn't execute\n> > > > >> \"git\": file name too long\". I've noticed that the most pronounced\n> > > > >> effect is that I cannot see the file diffs (or sometimes the file name\n> > > > >> list) for any of the commits. I don't know the exact repro, but I've\n> > > > >> narrowed down the following things:\n> > > > >>\n> > > > >> - This does not happen with the same repo if I use a system that has\n> > > > >> git 2.19.0.windows.1 on another machine.\n> > > > >> - This does not happen on my current machine in a freshly cloned repo.\n> > > > >\n> > > > >\n> > > > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?\n> > > > >\n> > > > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\\repo may not have issues, but the same repository cloned to C:\\Users\\Bryan\\Documents\\workspaces\\repo may.\n> > > > >\n> > > > >>\n> > > > >> However, as soon as the remote updates with any changes on a given\n> > > > >> fetch/pull, the repo is put in a bad state permanently.\n> > > > >>\n> > > > >> I've pasted the output from gitk below...\n> > > > >>\n> > > > >> couldn't execute \"git\": file name too long\n> > > > >> couldn't execute \"git\": file name too long\n> > > > >>     while executing\n> > > > >> \"open $cmd r\"\n> > > > >>     (procedure \"getallcommits\" line 48)\n> > > > >>     invoked from within\n> > > > >> \"getallcommits\"\n> > > > >>     (procedure \"readcache\" line 80)\n> > > > >>     invoked from within\n> > > > >> \"readcache file827e200\"\n> > > > >>     (\"eval\" body line 1)\n> > > > >>     invoked from within\n> > > > >> \"eval $script\"\n> > > > >>     (procedure \"dorunq\" line 11)\n> > > > >>     invoked from within\n> > > > >> \"dorunq\"\n> > > > >>     (\"after\" script)\n> > > > >>\n> > > > >> Happy to gather whatever data needed.\n> > > > >> Thanks!\n> > > > >> - Bret Barkelew\n> > > >\n> >\n"},{"id":"374124","messageId":"CAGTkKajYiyT_OtX1mQECvxjvKXndjBYAqwgKMimJrroPAAvZJA@mail.gmail.com","threadId":"50150","inReplyTo":"CAGTkKagTCw-EcMo3M1P3XVtjbTcm4HPjCWGZ1sM_NnJwH7v_hg@mail.gmail.com","subject":"Re: git version 2.20.1.windows.1 throws file name too long in gitk","fromName":"Bret Barkelew","fromEmail":"bret@corthon.com","sentAt":"2019-04-18T18:16:07Z","receivedAt":"2019-04-18T18:16:24Z","isPatch":false,"sender":{"key":"bret@corthon.com","avatar":"https://gravatar.com/avatar/9a370be172af79638f919295074527b53afe3147b7df1251a45ae93d6498f376?d=mp&s=160"},"body":"This issue is now being reported by more users inside MS. I'll also\nreach out to the Git for Windows advocacy group to see if they have\nany ideas.\n\nI have not had time to figure out the inner workings of Tcl/Tk. Is\nthere any way to turn on tracing/logging in Git for which commands are\nbeing called by gitk?\n\nOn Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew <bret@corthon.com> wrote:\n>\n> On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> >\n> > Hi Bret,\n> >\n> > in that case, please try to find a way to trace the commands in a Tcl/Tk\n> > program (which gitk is) and see which command triggers the error.\n>\n> Er... that's a little out of my depth. I'll see if I can find time to learn.\n> Meanwhile, is there any way to request better instrumentation for the\n> error dialog so this data could have been collected for me?\n>\n> >\n> > Ciao,\n> > Johannes\n> >\n> >\n> > On Wed, 9 Jan 2019, Bret Barkelew wrote:\n> >\n> > > Will try to reply in-line, when appropriate.\n> > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still\n> > > has the issue.\n> > >\n> > > - Bret\n> > >\n> > >\n> > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin\n> > > <Johannes.Schindelin@gmx.de> wrote:\n> > > >\n> > > > Hi Bret,\n> > > >\n> > > >\n> > > > On Thu, 3 Jan 2019, Bret Barkelew wrote:\n> > > >\n> > > > > They are the exact same path (with a different drive letter).\n> > > >\n> > > > [it's a bit hard to follow the thread if you top-post a reply to an\n> > > > inline-replied answer, maybe imitate the style of other mails in the\n> > > > future.]\n> > > >\n> > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1\n> > > > > and installed 2.19.0 on the failing system, and the older version of\n> > > > > Git works.\n> > > > > I've also tried a suggested fix I saw elsewhere to enable long path\n> > > > > names in the Windows registry, which did not resolve the issue with\n> > > > > git 2.20.1.\n> > > > >\n> > > > > Happy to collect any additional data.\n> > > >\n> > > > Please try the latest snapshot at\n> > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug\n> > > > might be fixed via\n> > > > https://github.com/git-for-windows/MINGW-packages/pull/32).\n> > > >\n> > > > Ciao,\n> > > > Johannes\n> > > >\n> > > > > - Bret\n> > > > >\n> > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:\n> > > > > >\n> > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:\n> > > > > >>\n> > > > > >> When I open gitk in a particular repository under this version of Git\n> > > > > >> for Windows, I now get a dialog box that says \"Error: couldn't execute\n> > > > > >> \"git\": file name too long\". I've noticed that the most pronounced\n> > > > > >> effect is that I cannot see the file diffs (or sometimes the file name\n> > > > > >> list) for any of the commits. I don't know the exact repro, but I've\n> > > > > >> narrowed down the following things:\n> > > > > >>\n> > > > > >> - This does not happen with the same repo if I use a system that has\n> > > > > >> git 2.19.0.windows.1 on another machine.\n> > > > > >> - This does not happen on my current machine in a freshly cloned repo.\n> > > > > >\n> > > > > >\n> > > > > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?\n> > > > > >\n> > > > > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\\repo may not have issues, but the same repository cloned to C:\\Users\\Bryan\\Documents\\workspaces\\repo may.\n> > > > > >\n> > > > > >>\n> > > > > >> However, as soon as the remote updates with any changes on a given\n> > > > > >> fetch/pull, the repo is put in a bad state permanently.\n> > > > > >>\n> > > > > >> I've pasted the output from gitk below...\n> > > > > >>\n> > > > > >> couldn't execute \"git\": file name too long\n> > > > > >> couldn't execute \"git\": file name too long\n> > > > > >>     while executing\n> > > > > >> \"open $cmd r\"\n> > > > > >>     (procedure \"getallcommits\" line 48)\n> > > > > >>     invoked from within\n> > > > > >> \"getallcommits\"\n> > > > > >>     (procedure \"readcache\" line 80)\n> > > > > >>     invoked from within\n> > > > > >> \"readcache file827e200\"\n> > > > > >>     (\"eval\" body line 1)\n> > > > > >>     invoked from within\n> > > > > >> \"eval $script\"\n> > > > > >>     (procedure \"dorunq\" line 11)\n> > > > > >>     invoked from within\n> > > > > >> \"dorunq\"\n> > > > > >>     (\"after\" script)\n> > > > > >>\n> > > > > >> Happy to gather whatever data needed.\n> > > > > >> Thanks!\n> > > > > >> - Bret Barkelew\n> > > > >\n> > >\n"},{"id":"374609","messageId":"nycvar.QRO.7.76.6.1904271722290.45@tvgsbejvaqbjf.bet","threadId":"50150","inReplyTo":"CAGTkKajYiyT_OtX1mQECvxjvKXndjBYAqwgKMimJrroPAAvZJA@mail.gmail.com","subject":"Re: git version 2.20.1.windows.1 throws file name too long in gitk","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-04-27T23:20:42Z","receivedAt":"2019-04-27T23:20:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Bret,\n\nOn Thu, 18 Apr 2019, Bret Barkelew wrote:\n\n> This issue is now being reported by more users inside MS. I'll also\n> reach out to the Git for Windows advocacy group to see if they have\n> any ideas.\n>\n> I have not had time to figure out the inner workings of Tcl/Tk. Is\n> there any way to turn on tracing/logging in Git for which commands are\n> being called by gitk?\n\nThank you for reaching out with detailed information internally, I am\nhappy to report that together with the help of Max Kirillov, this is now\nresolved and a snapshot is available from\nhttps://wingit.blob.core.windows.net/files/index.html that has the fix.\n\nCiao,\nJohannes\n\n> On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew <bret@corthon.com> wrote:\n> >\n> > On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin\n> > <Johannes.Schindelin@gmx.de> wrote:\n> > >\n> > > Hi Bret,\n> > >\n> > > in that case, please try to find a way to trace the commands in a Tcl/Tk\n> > > program (which gitk is) and see which command triggers the error.\n> >\n> > Er... that's a little out of my depth. I'll see if I can find time to learn.\n> > Meanwhile, is there any way to request better instrumentation for the\n> > error dialog so this data could have been collected for me?\n> >\n> > >\n> > > Ciao,\n> > > Johannes\n> > >\n> > >\n> > > On Wed, 9 Jan 2019, Bret Barkelew wrote:\n> > >\n> > > > Will try to reply in-line, when appropriate.\n> > > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still\n> > > > has the issue.\n> > > >\n> > > > - Bret\n> > > >\n> > > >\n> > > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin\n> > > > <Johannes.Schindelin@gmx.de> wrote:\n> > > > >\n> > > > > Hi Bret,\n> > > > >\n> > > > >\n> > > > > On Thu, 3 Jan 2019, Bret Barkelew wrote:\n> > > > >\n> > > > > > They are the exact same path (with a different drive letter).\n> > > > >\n> > > > > [it's a bit hard to follow the thread if you top-post a reply to an\n> > > > > inline-replied answer, maybe imitate the style of other mails in the\n> > > > > future.]\n> > > > >\n> > > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1\n> > > > > > and installed 2.19.0 on the failing system, and the older version of\n> > > > > > Git works.\n> > > > > > I've also tried a suggested fix I saw elsewhere to enable long path\n> > > > > > names in the Windows registry, which did not resolve the issue with\n> > > > > > git 2.20.1.\n> > > > > >\n> > > > > > Happy to collect any additional data.\n> > > > >\n> > > > > Please try the latest snapshot at\n> > > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug\n> > > > > might be fixed via\n> > > > > https://github.com/git-for-windows/MINGW-packages/pull/32).\n> > > > >\n> > > > > Ciao,\n> > > > > Johannes\n> > > > >\n> > > > > > - Bret\n> > > > > >\n> > > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:\n> > > > > > >\n> > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:\n> > > > > > >>\n> > > > > > >> When I open gitk in a particular repository under this version of Git\n> > > > > > >> for Windows, I now get a dialog box that says \"Error: couldn't execute\n> > > > > > >> \"git\": file name too long\". I've noticed that the most pronounced\n> > > > > > >> effect is that I cannot see the file diffs (or sometimes the file name\n> > > > > > >> list) for any of the commits. I don't know the exact repro, but I've\n> > > > > > >> narrowed down the following things:\n> > > > > > >>\n> > > > > > >> - This does not happen with the same repo if I use a system that has\n> > > > > > >> git 2.19.0.windows.1 on another machine.\n> > > > > > >> - This does not happen on my current machine in a freshly cloned repo.\n> > > > > > >\n> > > > > > >\n> > > > > > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?\n> > > > > > >\n> > > > > > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\\repo may not have issues, but the same repository cloned to C:\\Users\\Bryan\\Documents\\workspaces\\repo may.\n> > > > > > >\n> > > > > > >>\n> > > > > > >> However, as soon as the remote updates with any changes on a given\n> > > > > > >> fetch/pull, the repo is put in a bad state permanently.\n> > > > > > >>\n> > > > > > >> I've pasted the output from gitk below...\n> > > > > > >>\n> > > > > > >> couldn't execute \"git\": file name too long\n> > > > > > >> couldn't execute \"git\": file name too long\n> > > > > > >>     while executing\n> > > > > > >> \"open $cmd r\"\n> > > > > > >>     (procedure \"getallcommits\" line 48)\n> > > > > > >>     invoked from within\n> > > > > > >> \"getallcommits\"\n> > > > > > >>     (procedure \"readcache\" line 80)\n> > > > > > >>     invoked from within\n> > > > > > >> \"readcache file827e200\"\n> > > > > > >>     (\"eval\" body line 1)\n> > > > > > >>     invoked from within\n> > > > > > >> \"eval $script\"\n> > > > > > >>     (procedure \"dorunq\" line 11)\n> > > > > > >>     invoked from within\n> > > > > > >> \"dorunq\"\n> > > > > > >>     (\"after\" script)\n> > > > > > >>\n> > > > > > >> Happy to gather whatever data needed.\n> > > > > > >> Thanks!\n> > > > > > >> - Bret Barkelew\n> > > > > >\n> > > >\n>\n"},{"id":"376402","messageId":"CAGTkKagwzceU51O6dK_6-MRZdEW52-xEFoGBVf9z9XLVEJoAGg@mail.gmail.com","threadId":"50150","inReplyTo":"nycvar.QRO.7.76.6.1904271722290.45@tvgsbejvaqbjf.bet","subject":"Re: git version 2.20.1.windows.1 throws file name too long in gitk","fromName":"Bret Barkelew","fromEmail":"bret@corthon.com","sentAt":"2019-05-29T16:40:40Z","receivedAt":"2019-05-29T16:40:56Z","isPatch":false,"sender":{"key":"bret@corthon.com","avatar":"https://gravatar.com/avatar/9a370be172af79638f919295074527b53afe3147b7df1251a45ae93d6498f376?d=mp&s=160"},"body":"I know it's an incredibly late reply, but I have not seen this issue\nreappear since the patches. Thank you very much for helping!\n\n- Bret\n\nOn Sat, Apr 27, 2019 at 4:20 PM Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n>\n> Hi Bret,\n>\n> On Thu, 18 Apr 2019, Bret Barkelew wrote:\n>\n> > This issue is now being reported by more users inside MS. I'll also\n> > reach out to the Git for Windows advocacy group to see if they have\n> > any ideas.\n> >\n> > I have not had time to figure out the inner workings of Tcl/Tk. Is\n> > there any way to turn on tracing/logging in Git for which commands are\n> > being called by gitk?\n>\n> Thank you for reaching out with detailed information internally, I am\n> happy to report that together with the help of Max Kirillov, this is now\n> resolved and a snapshot is available from\n> https://wingit.blob.core.windows.net/files/index.html that has the fix.\n>\n> Ciao,\n> Johannes\n>\n> > On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew <bret@corthon.com> wrote:\n> > >\n> > > On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin\n> > > <Johannes.Schindelin@gmx.de> wrote:\n> > > >\n> > > > Hi Bret,\n> > > >\n> > > > in that case, please try to find a way to trace the commands in a Tcl/Tk\n> > > > program (which gitk is) and see which command triggers the error.\n> > >\n> > > Er... that's a little out of my depth. I'll see if I can find time to learn.\n> > > Meanwhile, is there any way to request better instrumentation for the\n> > > error dialog so this data could have been collected for me?\n> > >\n> > > >\n> > > > Ciao,\n> > > > Johannes\n> > > >\n> > > >\n> > > > On Wed, 9 Jan 2019, Bret Barkelew wrote:\n> > > >\n> > > > > Will try to reply in-line, when appropriate.\n> > > > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still\n> > > > > has the issue.\n> > > > >\n> > > > > - Bret\n> > > > >\n> > > > >\n> > > > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin\n> > > > > <Johannes.Schindelin@gmx.de> wrote:\n> > > > > >\n> > > > > > Hi Bret,\n> > > > > >\n> > > > > >\n> > > > > > On Thu, 3 Jan 2019, Bret Barkelew wrote:\n> > > > > >\n> > > > > > > They are the exact same path (with a different drive letter).\n> > > > > >\n> > > > > > [it's a bit hard to follow the thread if you top-post a reply to an\n> > > > > > inline-replied answer, maybe imitate the style of other mails in the\n> > > > > > future.]\n> > > > > >\n> > > > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1\n> > > > > > > and installed 2.19.0 on the failing system, and the older version of\n> > > > > > > Git works.\n> > > > > > > I've also tried a suggested fix I saw elsewhere to enable long path\n> > > > > > > names in the Windows registry, which did not resolve the issue with\n> > > > > > > git 2.20.1.\n> > > > > > >\n> > > > > > > Happy to collect any additional data.\n> > > > > >\n> > > > > > Please try the latest snapshot at\n> > > > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug\n> > > > > > might be fixed via\n> > > > > > https://github.com/git-for-windows/MINGW-packages/pull/32).\n> > > > > >\n> > > > > > Ciao,\n> > > > > > Johannes\n> > > > > >\n> > > > > > > - Bret\n> > > > > > >\n> > > > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:\n> > > > > > > >\n> > > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:\n> > > > > > > >>\n> > > > > > > >> When I open gitk in a particular repository under this version of Git\n> > > > > > > >> for Windows, I now get a dialog box that says \"Error: couldn't execute\n> > > > > > > >> \"git\": file name too long\". I've noticed that the most pronounced\n> > > > > > > >> effect is that I cannot see the file diffs (or sometimes the file name\n> > > > > > > >> list) for any of the commits. I don't know the exact repro, but I've\n> > > > > > > >> narrowed down the following things:\n> > > > > > > >>\n> > > > > > > >> - This does not happen with the same repo if I use a system that has\n> > > > > > > >> git 2.19.0.windows.1 on another machine.\n> > > > > > > >> - This does not happen on my current machine in a freshly cloned repo.\n> > > > > > > >\n> > > > > > > >\n> > > > > > > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?\n> > > > > > > >\n> > > > > > > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\\repo may not have issues, but the same repository cloned to C:\\Users\\Bryan\\Documents\\workspaces\\repo may.\n> > > > > > > >\n> > > > > > > >>\n> > > > > > > >> However, as soon as the remote updates with any changes on a given\n> > > > > > > >> fetch/pull, the repo is put in a bad state permanently.\n> > > > > > > >>\n> > > > > > > >> I've pasted the output from gitk below...\n> > > > > > > >>\n> > > > > > > >> couldn't execute \"git\": file name too long\n> > > > > > > >> couldn't execute \"git\": file name too long\n> > > > > > > >>     while executing\n> > > > > > > >> \"open $cmd r\"\n> > > > > > > >>     (procedure \"getallcommits\" line 48)\n> > > > > > > >>     invoked from within\n> > > > > > > >> \"getallcommits\"\n> > > > > > > >>     (procedure \"readcache\" line 80)\n> > > > > > > >>     invoked from within\n> > > > > > > >> \"readcache file827e200\"\n> > > > > > > >>     (\"eval\" body line 1)\n> > > > > > > >>     invoked from within\n> > > > > > > >> \"eval $script\"\n> > > > > > > >>     (procedure \"dorunq\" line 11)\n> > > > > > > >>     invoked from within\n> > > > > > > >> \"dorunq\"\n> > > > > > > >>     (\"after\" script)\n> > > > > > > >>\n> > > > > > > >> Happy to gather whatever data needed.\n> > > > > > > >> Thanks!\n> > > > > > > >> - Bret Barkelew\n> > > > > > >\n> > > > >\n> >\n"},{"id":"376411","messageId":"nycvar.QRO.7.76.6.1905292004380.44@tvgsbejvaqbjf.bet","threadId":"50150","inReplyTo":"CAGTkKagwzceU51O6dK_6-MRZdEW52-xEFoGBVf9z9XLVEJoAGg@mail.gmail.com","subject":"Re: git version 2.20.1.windows.1 throws file name too long in gitk","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-05-29T18:07:31Z","receivedAt":"2019-05-29T18:07:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Bret,\n\nOn Wed, 29 May 2019, Bret Barkelew wrote:\n\n> I know it's an incredibly late reply, but I have not seen this issue\n> reappear since the patches. Thank you very much for helping!\n\nIt might be late, but it is even more welcome! Thanks for the feedback\n(and I am particularly happy that it works for you).\n\nCiao,\nJohannes\n\nP.S.: For lurkers, I just realized that I never linked to the patches:\nhttps://github.com/git-for-windows/git/pull/2170\n\nAs this PR really only touches code that is already in Git for Windows,\nbut not yet in git.git, I think I'll try to find some time post-v2.22.0 to\nbrush up those gitk patches and contribute them to the Git mailing list\nfor review.\n\n> On Sat, Apr 27, 2019 at 4:20 PM Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> >\n> > Hi Bret,\n> >\n> > On Thu, 18 Apr 2019, Bret Barkelew wrote:\n> >\n> > > This issue is now being reported by more users inside MS. I'll also\n> > > reach out to the Git for Windows advocacy group to see if they have\n> > > any ideas.\n> > >\n> > > I have not had time to figure out the inner workings of Tcl/Tk. Is\n> > > there any way to turn on tracing/logging in Git for which commands are\n> > > being called by gitk?\n> >\n> > Thank you for reaching out with detailed information internally, I am\n> > happy to report that together with the help of Max Kirillov, this is now\n> > resolved and a snapshot is available from\n> > https://wingit.blob.core.windows.net/files/index.html that has the fix.\n> >\n> > Ciao,\n> > Johannes\n> >\n> > > On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew <bret@corthon.com> wrote:\n> > > >\n> > > > On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin\n> > > > <Johannes.Schindelin@gmx.de> wrote:\n> > > > >\n> > > > > Hi Bret,\n> > > > >\n> > > > > in that case, please try to find a way to trace the commands in a Tcl/Tk\n> > > > > program (which gitk is) and see which command triggers the error.\n> > > >\n> > > > Er... that's a little out of my depth. I'll see if I can find time to learn.\n> > > > Meanwhile, is there any way to request better instrumentation for the\n> > > > error dialog so this data could have been collected for me?\n> > > >\n> > > > >\n> > > > > Ciao,\n> > > > > Johannes\n> > > > >\n> > > > >\n> > > > > On Wed, 9 Jan 2019, Bret Barkelew wrote:\n> > > > >\n> > > > > > Will try to reply in-line, when appropriate.\n> > > > > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still\n> > > > > > has the issue.\n> > > > > >\n> > > > > > - Bret\n> > > > > >\n> > > > > >\n> > > > > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin\n> > > > > > <Johannes.Schindelin@gmx.de> wrote:\n> > > > > > >\n> > > > > > > Hi Bret,\n> > > > > > >\n> > > > > > >\n> > > > > > > On Thu, 3 Jan 2019, Bret Barkelew wrote:\n> > > > > > >\n> > > > > > > > They are the exact same path (with a different drive letter).\n> > > > > > >\n> > > > > > > [it's a bit hard to follow the thread if you top-post a reply to an\n> > > > > > > inline-replied answer, maybe imitate the style of other mails in the\n> > > > > > > future.]\n> > > > > > >\n> > > > > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1\n> > > > > > > > and installed 2.19.0 on the failing system, and the older version of\n> > > > > > > > Git works.\n> > > > > > > > I've also tried a suggested fix I saw elsewhere to enable long path\n> > > > > > > > names in the Windows registry, which did not resolve the issue with\n> > > > > > > > git 2.20.1.\n> > > > > > > >\n> > > > > > > > Happy to collect any additional data.\n> > > > > > >\n> > > > > > > Please try the latest snapshot at\n> > > > > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug\n> > > > > > > might be fixed via\n> > > > > > > https://github.com/git-for-windows/MINGW-packages/pull/32).\n> > > > > > >\n> > > > > > > Ciao,\n> > > > > > > Johannes\n> > > > > > >\n> > > > > > > > - Bret\n> > > > > > > >\n> > > > > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:\n> > > > > > > > >\n> > > > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:\n> > > > > > > > >>\n> > > > > > > > >> When I open gitk in a particular repository under this version of Git\n> > > > > > > > >> for Windows, I now get a dialog box that says \"Error: couldn't execute\n> > > > > > > > >> \"git\": file name too long\". I've noticed that the most pronounced\n> > > > > > > > >> effect is that I cannot see the file diffs (or sometimes the file name\n> > > > > > > > >> list) for any of the commits. I don't know the exact repro, but I've\n> > > > > > > > >> narrowed down the following things:\n> > > > > > > > >>\n> > > > > > > > >> - This does not happen with the same repo if I use a system that has\n> > > > > > > > >> git 2.19.0.windows.1 on another machine.\n> > > > > > > > >> - This does not happen on my current machine in a freshly cloned repo.\n> > > > > > > > >\n> > > > > > > > >\n> > > > > > > > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?\n> > > > > > > > >\n> > > > > > > > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\\repo may not have issues, but the same repository cloned to C:\\Users\\Bryan\\Documents\\workspaces\\repo may.\n> > > > > > > > >\n> > > > > > > > >>\n> > > > > > > > >> However, as soon as the remote updates with any changes on a given\n> > > > > > > > >> fetch/pull, the repo is put in a bad state permanently.\n> > > > > > > > >>\n> > > > > > > > >> I've pasted the output from gitk below...\n> > > > > > > > >>\n> > > > > > > > >> couldn't execute \"git\": file name too long\n> > > > > > > > >> couldn't execute \"git\": file name too long\n> > > > > > > > >>     while executing\n> > > > > > > > >> \"open $cmd r\"\n> > > > > > > > >>     (procedure \"getallcommits\" line 48)\n> > > > > > > > >>     invoked from within\n> > > > > > > > >> \"getallcommits\"\n> > > > > > > > >>     (procedure \"readcache\" line 80)\n> > > > > > > > >>     invoked from within\n> > > > > > > > >> \"readcache file827e200\"\n> > > > > > > > >>     (\"eval\" body line 1)\n> > > > > > > > >>     invoked from within\n> > > > > > > > >> \"eval $script\"\n> > > > > > > > >>     (procedure \"dorunq\" line 11)\n> > > > > > > > >>     invoked from within\n> > > > > > > > >> \"dorunq\"\n> > > > > > > > >>     (\"after\" script)\n> > > > > > > > >>\n> > > > > > > > >> Happy to gather whatever data needed.\n> > > > > > > > >> Thanks!\n> > > > > > > > >> - Bret Barkelew\n> > > > > > > >\n> > > > > >\n> > >\n>\n"}]}