* git version 2.20.1.windows.1 throws file name too long in gitk @ 2019-01-04 2:21 Bret Barkelew [not found] ` <CAGyf7-HcncFOfmm5McEkOvCTkHNdePDSEQDZwEAK=z1bmC=QKw@mail.gmail.com> 0 siblings, 1 reply; 10+ messages in thread From: Bret Barkelew @ 2019-01-04 2:21 UTC (permalink / raw) To: git When I open gitk in a particular repository under this version of Git for Windows, I now get a dialog box that says "Error: couldn't execute "git": file name too long". I've noticed that the most pronounced effect is that I cannot see the file diffs (or sometimes the file name list) for any of the commits. I don't know the exact repro, but I've narrowed down the following things: - This does not happen with the same repo if I use a system that has git 2.19.0.windows.1 on another machine. - This does not happen on my current machine in a freshly cloned repo. However, as soon as the remote updates with any changes on a given fetch/pull, the repo is put in a bad state permanently. I've pasted the output from gitk below... couldn't execute "git": file name too long couldn't execute "git": file name too long while executing "open $cmd r" (procedure "getallcommits" line 48) invoked from within "getallcommits" (procedure "readcache" line 80) invoked from within "readcache file827e200" ("eval" body line 1) invoked from within "eval $script" (procedure "dorunq" line 11) invoked from within "dorunq" ("after" script) Happy to gather whatever data needed. Thanks! - Bret Barkelew ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <CAGyf7-HcncFOfmm5McEkOvCTkHNdePDSEQDZwEAK=z1bmC=QKw@mail.gmail.com>]
* Re: git version 2.20.1.windows.1 throws file name too long in gitk [not found] ` <CAGyf7-HcncFOfmm5McEkOvCTkHNdePDSEQDZwEAK=z1bmC=QKw@mail.gmail.com> @ 2019-01-04 3:38 ` Bret Barkelew 2019-01-09 18:39 ` Johannes Schindelin 0 siblings, 1 reply; 10+ messages in thread From: Bret Barkelew @ 2019-01-04 3:38 UTC (permalink / raw) To: Bryan Turner; +Cc: git They are the exact same path (with a different drive letter). Another thing I've been able to confirm is I uninstalled git 2.20.1 and installed 2.19.0 on the failing system, and the older version of Git works. I've also tried a suggested fix I saw elsewhere to enable long path names in the Windows registry, which did not resolve the issue with git 2.20.1. Happy to collect any additional data. - Bret On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote: > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote: >> >> When I open gitk in a particular repository under this version of Git >> for Windows, I now get a dialog box that says "Error: couldn't execute >> "git": file name too long". I've noticed that the most pronounced >> effect is that I cannot see the file diffs (or sometimes the file name >> list) for any of the commits. I don't know the exact repro, but I've >> narrowed down the following things: >> >> - This does not happen with the same repo if I use a system that has >> git 2.19.0.windows.1 on another machine. >> - This does not happen on my current machine in a freshly cloned repo. > > > 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? > > 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. > >> >> However, as soon as the remote updates with any changes on a given >> fetch/pull, the repo is put in a bad state permanently. >> >> I've pasted the output from gitk below... >> >> couldn't execute "git": file name too long >> couldn't execute "git": file name too long >> while executing >> "open $cmd r" >> (procedure "getallcommits" line 48) >> invoked from within >> "getallcommits" >> (procedure "readcache" line 80) >> invoked from within >> "readcache file827e200" >> ("eval" body line 1) >> invoked from within >> "eval $script" >> (procedure "dorunq" line 11) >> invoked from within >> "dorunq" >> ("after" script) >> >> Happy to gather whatever data needed. >> Thanks! >> - Bret Barkelew ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git version 2.20.1.windows.1 throws file name too long in gitk 2019-01-04 3:38 ` Bret Barkelew @ 2019-01-09 18:39 ` Johannes Schindelin 2019-01-09 18:48 ` Bret Barkelew 0 siblings, 1 reply; 10+ messages in thread From: Johannes Schindelin @ 2019-01-09 18:39 UTC (permalink / raw) To: Bret Barkelew; +Cc: Bryan Turner, git [-- Attachment #1: Type: text/plain, Size: 2921 bytes --] Hi Bret, On Thu, 3 Jan 2019, Bret Barkelew wrote: > They are the exact same path (with a different drive letter). [it's a bit hard to follow the thread if you top-post a reply to an inline-replied answer, maybe imitate the style of other mails in the future.] > Another thing I've been able to confirm is I uninstalled git 2.20.1 > and installed 2.19.0 on the failing system, and the older version of > Git works. > I've also tried a suggested fix I saw elsewhere to enable long path > names in the Windows registry, which did not resolve the issue with > git 2.20.1. > > Happy to collect any additional data. Please try the latest snapshot at https://wingit.blob.core.windows.net/files/index.html (I *think* the bug might be fixed via https://github.com/git-for-windows/MINGW-packages/pull/32). Ciao, Johannes > - Bret > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote: > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote: > >> > >> When I open gitk in a particular repository under this version of Git > >> for Windows, I now get a dialog box that says "Error: couldn't execute > >> "git": file name too long". I've noticed that the most pronounced > >> effect is that I cannot see the file diffs (or sometimes the file name > >> list) for any of the commits. I don't know the exact repro, but I've > >> narrowed down the following things: > >> > >> - This does not happen with the same repo if I use a system that has > >> git 2.19.0.windows.1 on another machine. > >> - This does not happen on my current machine in a freshly cloned repo. > > > > > > 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? > > > > 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. > > > >> > >> However, as soon as the remote updates with any changes on a given > >> fetch/pull, the repo is put in a bad state permanently. > >> > >> I've pasted the output from gitk below... > >> > >> couldn't execute "git": file name too long > >> couldn't execute "git": file name too long > >> while executing > >> "open $cmd r" > >> (procedure "getallcommits" line 48) > >> invoked from within > >> "getallcommits" > >> (procedure "readcache" line 80) > >> invoked from within > >> "readcache file827e200" > >> ("eval" body line 1) > >> invoked from within > >> "eval $script" > >> (procedure "dorunq" line 11) > >> invoked from within > >> "dorunq" > >> ("after" script) > >> > >> Happy to gather whatever data needed. > >> Thanks! > >> - Bret Barkelew > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git version 2.20.1.windows.1 throws file name too long in gitk 2019-01-09 18:39 ` Johannes Schindelin @ 2019-01-09 18:48 ` Bret Barkelew 2019-01-10 15:19 ` Johannes Schindelin 0 siblings, 1 reply; 10+ messages in thread From: Bret Barkelew @ 2019-01-09 18:48 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Bryan Turner, git Will try to reply in-line, when appropriate. The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still has the issue. - Bret On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > Hi Bret, > > > On Thu, 3 Jan 2019, Bret Barkelew wrote: > > > They are the exact same path (with a different drive letter). > > [it's a bit hard to follow the thread if you top-post a reply to an > inline-replied answer, maybe imitate the style of other mails in the > future.] > > > Another thing I've been able to confirm is I uninstalled git 2.20.1 > > and installed 2.19.0 on the failing system, and the older version of > > Git works. > > I've also tried a suggested fix I saw elsewhere to enable long path > > names in the Windows registry, which did not resolve the issue with > > git 2.20.1. > > > > Happy to collect any additional data. > > Please try the latest snapshot at > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug > might be fixed via > https://github.com/git-for-windows/MINGW-packages/pull/32). > > Ciao, > Johannes > > > - Bret > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote: > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote: > > >> > > >> When I open gitk in a particular repository under this version of Git > > >> for Windows, I now get a dialog box that says "Error: couldn't execute > > >> "git": file name too long". I've noticed that the most pronounced > > >> effect is that I cannot see the file diffs (or sometimes the file name > > >> list) for any of the commits. I don't know the exact repro, but I've > > >> narrowed down the following things: > > >> > > >> - This does not happen with the same repo if I use a system that has > > >> git 2.19.0.windows.1 on another machine. > > >> - This does not happen on my current machine in a freshly cloned repo. > > > > > > > > > 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? > > > > > > 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. > > > > > >> > > >> However, as soon as the remote updates with any changes on a given > > >> fetch/pull, the repo is put in a bad state permanently. > > >> > > >> I've pasted the output from gitk below... > > >> > > >> couldn't execute "git": file name too long > > >> couldn't execute "git": file name too long > > >> while executing > > >> "open $cmd r" > > >> (procedure "getallcommits" line 48) > > >> invoked from within > > >> "getallcommits" > > >> (procedure "readcache" line 80) > > >> invoked from within > > >> "readcache file827e200" > > >> ("eval" body line 1) > > >> invoked from within > > >> "eval $script" > > >> (procedure "dorunq" line 11) > > >> invoked from within > > >> "dorunq" > > >> ("after" script) > > >> > > >> Happy to gather whatever data needed. > > >> Thanks! > > >> - Bret Barkelew > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git version 2.20.1.windows.1 throws file name too long in gitk 2019-01-09 18:48 ` Bret Barkelew @ 2019-01-10 15:19 ` Johannes Schindelin 2019-01-10 18:55 ` Bret Barkelew 0 siblings, 1 reply; 10+ messages in thread From: Johannes Schindelin @ 2019-01-10 15:19 UTC (permalink / raw) To: Bret Barkelew; +Cc: Bryan Turner, git [-- Attachment #1: Type: text/plain, Size: 3685 bytes --] Hi Bret, in that case, please try to find a way to trace the commands in a Tcl/Tk program (which gitk is) and see which command triggers the error. Ciao, Johannes On Wed, 9 Jan 2019, Bret Barkelew wrote: > Will try to reply in-line, when appropriate. > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still > has the issue. > > - Bret > > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > > > > Hi Bret, > > > > > > On Thu, 3 Jan 2019, Bret Barkelew wrote: > > > > > They are the exact same path (with a different drive letter). > > > > [it's a bit hard to follow the thread if you top-post a reply to an > > inline-replied answer, maybe imitate the style of other mails in the > > future.] > > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1 > > > and installed 2.19.0 on the failing system, and the older version of > > > Git works. > > > I've also tried a suggested fix I saw elsewhere to enable long path > > > names in the Windows registry, which did not resolve the issue with > > > git 2.20.1. > > > > > > Happy to collect any additional data. > > > > Please try the latest snapshot at > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug > > might be fixed via > > https://github.com/git-for-windows/MINGW-packages/pull/32). > > > > Ciao, > > Johannes > > > > > - Bret > > > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote: > > > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote: > > > >> > > > >> When I open gitk in a particular repository under this version of Git > > > >> for Windows, I now get a dialog box that says "Error: couldn't execute > > > >> "git": file name too long". I've noticed that the most pronounced > > > >> effect is that I cannot see the file diffs (or sometimes the file name > > > >> list) for any of the commits. I don't know the exact repro, but I've > > > >> narrowed down the following things: > > > >> > > > >> - This does not happen with the same repo if I use a system that has > > > >> git 2.19.0.windows.1 on another machine. > > > >> - This does not happen on my current machine in a freshly cloned repo. > > > > > > > > > > > > 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? > > > > > > > > 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. > > > > > > > >> > > > >> However, as soon as the remote updates with any changes on a given > > > >> fetch/pull, the repo is put in a bad state permanently. > > > >> > > > >> I've pasted the output from gitk below... > > > >> > > > >> couldn't execute "git": file name too long > > > >> couldn't execute "git": file name too long > > > >> while executing > > > >> "open $cmd r" > > > >> (procedure "getallcommits" line 48) > > > >> invoked from within > > > >> "getallcommits" > > > >> (procedure "readcache" line 80) > > > >> invoked from within > > > >> "readcache file827e200" > > > >> ("eval" body line 1) > > > >> invoked from within > > > >> "eval $script" > > > >> (procedure "dorunq" line 11) > > > >> invoked from within > > > >> "dorunq" > > > >> ("after" script) > > > >> > > > >> Happy to gather whatever data needed. > > > >> Thanks! > > > >> - Bret Barkelew > > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git version 2.20.1.windows.1 throws file name too long in gitk 2019-01-10 15:19 ` Johannes Schindelin @ 2019-01-10 18:55 ` Bret Barkelew 2019-04-18 18:16 ` Bret Barkelew 0 siblings, 1 reply; 10+ messages in thread From: Bret Barkelew @ 2019-01-10 18:55 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Bryan Turner, git On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > Hi Bret, > > in that case, please try to find a way to trace the commands in a Tcl/Tk > program (which gitk is) and see which command triggers the error. Er... that's a little out of my depth. I'll see if I can find time to learn. Meanwhile, is there any way to request better instrumentation for the error dialog so this data could have been collected for me? > > Ciao, > Johannes > > > On Wed, 9 Jan 2019, Bret Barkelew wrote: > > > Will try to reply in-line, when appropriate. > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still > > has the issue. > > > > - Bret > > > > > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin > > <Johannes.Schindelin@gmx.de> wrote: > > > > > > Hi Bret, > > > > > > > > > On Thu, 3 Jan 2019, Bret Barkelew wrote: > > > > > > > They are the exact same path (with a different drive letter). > > > > > > [it's a bit hard to follow the thread if you top-post a reply to an > > > inline-replied answer, maybe imitate the style of other mails in the > > > future.] > > > > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1 > > > > and installed 2.19.0 on the failing system, and the older version of > > > > Git works. > > > > I've also tried a suggested fix I saw elsewhere to enable long path > > > > names in the Windows registry, which did not resolve the issue with > > > > git 2.20.1. > > > > > > > > Happy to collect any additional data. > > > > > > Please try the latest snapshot at > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug > > > might be fixed via > > > https://github.com/git-for-windows/MINGW-packages/pull/32). > > > > > > Ciao, > > > Johannes > > > > > > > - Bret > > > > > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote: > > > > > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote: > > > > >> > > > > >> When I open gitk in a particular repository under this version of Git > > > > >> for Windows, I now get a dialog box that says "Error: couldn't execute > > > > >> "git": file name too long". I've noticed that the most pronounced > > > > >> effect is that I cannot see the file diffs (or sometimes the file name > > > > >> list) for any of the commits. I don't know the exact repro, but I've > > > > >> narrowed down the following things: > > > > >> > > > > >> - This does not happen with the same repo if I use a system that has > > > > >> git 2.19.0.windows.1 on another machine. > > > > >> - This does not happen on my current machine in a freshly cloned repo. > > > > > > > > > > > > > > > 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? > > > > > > > > > > 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. > > > > > > > > > >> > > > > >> However, as soon as the remote updates with any changes on a given > > > > >> fetch/pull, the repo is put in a bad state permanently. > > > > >> > > > > >> I've pasted the output from gitk below... > > > > >> > > > > >> couldn't execute "git": file name too long > > > > >> couldn't execute "git": file name too long > > > > >> while executing > > > > >> "open $cmd r" > > > > >> (procedure "getallcommits" line 48) > > > > >> invoked from within > > > > >> "getallcommits" > > > > >> (procedure "readcache" line 80) > > > > >> invoked from within > > > > >> "readcache file827e200" > > > > >> ("eval" body line 1) > > > > >> invoked from within > > > > >> "eval $script" > > > > >> (procedure "dorunq" line 11) > > > > >> invoked from within > > > > >> "dorunq" > > > > >> ("after" script) > > > > >> > > > > >> Happy to gather whatever data needed. > > > > >> Thanks! > > > > >> - Bret Barkelew > > > > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git version 2.20.1.windows.1 throws file name too long in gitk 2019-01-10 18:55 ` Bret Barkelew @ 2019-04-18 18:16 ` Bret Barkelew 2019-04-27 23:20 ` Johannes Schindelin 0 siblings, 1 reply; 10+ messages in thread From: Bret Barkelew @ 2019-04-18 18:16 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Bryan Turner, git This issue is now being reported by more users inside MS. I'll also reach out to the Git for Windows advocacy group to see if they have any ideas. I have not had time to figure out the inner workings of Tcl/Tk. Is there any way to turn on tracing/logging in Git for which commands are being called by gitk? On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew <bret@corthon.com> wrote: > > On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > > > > Hi Bret, > > > > in that case, please try to find a way to trace the commands in a Tcl/Tk > > program (which gitk is) and see which command triggers the error. > > Er... that's a little out of my depth. I'll see if I can find time to learn. > Meanwhile, is there any way to request better instrumentation for the > error dialog so this data could have been collected for me? > > > > > Ciao, > > Johannes > > > > > > On Wed, 9 Jan 2019, Bret Barkelew wrote: > > > > > Will try to reply in-line, when appropriate. > > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still > > > has the issue. > > > > > > - Bret > > > > > > > > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin > > > <Johannes.Schindelin@gmx.de> wrote: > > > > > > > > Hi Bret, > > > > > > > > > > > > On Thu, 3 Jan 2019, Bret Barkelew wrote: > > > > > > > > > They are the exact same path (with a different drive letter). > > > > > > > > [it's a bit hard to follow the thread if you top-post a reply to an > > > > inline-replied answer, maybe imitate the style of other mails in the > > > > future.] > > > > > > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1 > > > > > and installed 2.19.0 on the failing system, and the older version of > > > > > Git works. > > > > > I've also tried a suggested fix I saw elsewhere to enable long path > > > > > names in the Windows registry, which did not resolve the issue with > > > > > git 2.20.1. > > > > > > > > > > Happy to collect any additional data. > > > > > > > > Please try the latest snapshot at > > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug > > > > might be fixed via > > > > https://github.com/git-for-windows/MINGW-packages/pull/32). > > > > > > > > Ciao, > > > > Johannes > > > > > > > > > - Bret > > > > > > > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote: > > > > > > > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote: > > > > > >> > > > > > >> When I open gitk in a particular repository under this version of Git > > > > > >> for Windows, I now get a dialog box that says "Error: couldn't execute > > > > > >> "git": file name too long". I've noticed that the most pronounced > > > > > >> effect is that I cannot see the file diffs (or sometimes the file name > > > > > >> list) for any of the commits. I don't know the exact repro, but I've > > > > > >> narrowed down the following things: > > > > > >> > > > > > >> - This does not happen with the same repo if I use a system that has > > > > > >> git 2.19.0.windows.1 on another machine. > > > > > >> - This does not happen on my current machine in a freshly cloned repo. > > > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > 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. > > > > > > > > > > > >> > > > > > >> However, as soon as the remote updates with any changes on a given > > > > > >> fetch/pull, the repo is put in a bad state permanently. > > > > > >> > > > > > >> I've pasted the output from gitk below... > > > > > >> > > > > > >> couldn't execute "git": file name too long > > > > > >> couldn't execute "git": file name too long > > > > > >> while executing > > > > > >> "open $cmd r" > > > > > >> (procedure "getallcommits" line 48) > > > > > >> invoked from within > > > > > >> "getallcommits" > > > > > >> (procedure "readcache" line 80) > > > > > >> invoked from within > > > > > >> "readcache file827e200" > > > > > >> ("eval" body line 1) > > > > > >> invoked from within > > > > > >> "eval $script" > > > > > >> (procedure "dorunq" line 11) > > > > > >> invoked from within > > > > > >> "dorunq" > > > > > >> ("after" script) > > > > > >> > > > > > >> Happy to gather whatever data needed. > > > > > >> Thanks! > > > > > >> - Bret Barkelew > > > > > > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git version 2.20.1.windows.1 throws file name too long in gitk 2019-04-18 18:16 ` Bret Barkelew @ 2019-04-27 23:20 ` Johannes Schindelin 2019-05-29 16:40 ` Bret Barkelew 0 siblings, 1 reply; 10+ messages in thread From: Johannes Schindelin @ 2019-04-27 23:20 UTC (permalink / raw) To: Bret Barkelew; +Cc: Bryan Turner, git [-- Attachment #1: Type: text/plain, Size: 5467 bytes --] Hi Bret, On Thu, 18 Apr 2019, Bret Barkelew wrote: > This issue is now being reported by more users inside MS. I'll also > reach out to the Git for Windows advocacy group to see if they have > any ideas. > > I have not had time to figure out the inner workings of Tcl/Tk. Is > there any way to turn on tracing/logging in Git for which commands are > being called by gitk? Thank you for reaching out with detailed information internally, I am happy to report that together with the help of Max Kirillov, this is now resolved and a snapshot is available from https://wingit.blob.core.windows.net/files/index.html that has the fix. Ciao, Johannes > On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew <bret@corthon.com> wrote: > > > > On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin > > <Johannes.Schindelin@gmx.de> wrote: > > > > > > Hi Bret, > > > > > > in that case, please try to find a way to trace the commands in a Tcl/Tk > > > program (which gitk is) and see which command triggers the error. > > > > Er... that's a little out of my depth. I'll see if I can find time to learn. > > Meanwhile, is there any way to request better instrumentation for the > > error dialog so this data could have been collected for me? > > > > > > > > Ciao, > > > Johannes > > > > > > > > > On Wed, 9 Jan 2019, Bret Barkelew wrote: > > > > > > > Will try to reply in-line, when appropriate. > > > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still > > > > has the issue. > > > > > > > > - Bret > > > > > > > > > > > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin > > > > <Johannes.Schindelin@gmx.de> wrote: > > > > > > > > > > Hi Bret, > > > > > > > > > > > > > > > On Thu, 3 Jan 2019, Bret Barkelew wrote: > > > > > > > > > > > They are the exact same path (with a different drive letter). > > > > > > > > > > [it's a bit hard to follow the thread if you top-post a reply to an > > > > > inline-replied answer, maybe imitate the style of other mails in the > > > > > future.] > > > > > > > > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1 > > > > > > and installed 2.19.0 on the failing system, and the older version of > > > > > > Git works. > > > > > > I've also tried a suggested fix I saw elsewhere to enable long path > > > > > > names in the Windows registry, which did not resolve the issue with > > > > > > git 2.20.1. > > > > > > > > > > > > Happy to collect any additional data. > > > > > > > > > > Please try the latest snapshot at > > > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug > > > > > might be fixed via > > > > > https://github.com/git-for-windows/MINGW-packages/pull/32). > > > > > > > > > > Ciao, > > > > > Johannes > > > > > > > > > > > - Bret > > > > > > > > > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote: > > > > > > > > > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote: > > > > > > >> > > > > > > >> When I open gitk in a particular repository under this version of Git > > > > > > >> for Windows, I now get a dialog box that says "Error: couldn't execute > > > > > > >> "git": file name too long". I've noticed that the most pronounced > > > > > > >> effect is that I cannot see the file diffs (or sometimes the file name > > > > > > >> list) for any of the commits. I don't know the exact repro, but I've > > > > > > >> narrowed down the following things: > > > > > > >> > > > > > > >> - This does not happen with the same repo if I use a system that has > > > > > > >> git 2.19.0.windows.1 on another machine. > > > > > > >> - This does not happen on my current machine in a freshly cloned repo. > > > > > > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > >> > > > > > > >> However, as soon as the remote updates with any changes on a given > > > > > > >> fetch/pull, the repo is put in a bad state permanently. > > > > > > >> > > > > > > >> I've pasted the output from gitk below... > > > > > > >> > > > > > > >> couldn't execute "git": file name too long > > > > > > >> couldn't execute "git": file name too long > > > > > > >> while executing > > > > > > >> "open $cmd r" > > > > > > >> (procedure "getallcommits" line 48) > > > > > > >> invoked from within > > > > > > >> "getallcommits" > > > > > > >> (procedure "readcache" line 80) > > > > > > >> invoked from within > > > > > > >> "readcache file827e200" > > > > > > >> ("eval" body line 1) > > > > > > >> invoked from within > > > > > > >> "eval $script" > > > > > > >> (procedure "dorunq" line 11) > > > > > > >> invoked from within > > > > > > >> "dorunq" > > > > > > >> ("after" script) > > > > > > >> > > > > > > >> Happy to gather whatever data needed. > > > > > > >> Thanks! > > > > > > >> - Bret Barkelew > > > > > > > > > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git version 2.20.1.windows.1 throws file name too long in gitk 2019-04-27 23:20 ` Johannes Schindelin @ 2019-05-29 16:40 ` Bret Barkelew 2019-05-29 18:07 ` Johannes Schindelin 0 siblings, 1 reply; 10+ messages in thread From: Bret Barkelew @ 2019-05-29 16:40 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Bryan Turner, git I know it's an incredibly late reply, but I have not seen this issue reappear since the patches. Thank you very much for helping! - Bret On Sat, Apr 27, 2019 at 4:20 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > Hi Bret, > > On Thu, 18 Apr 2019, Bret Barkelew wrote: > > > This issue is now being reported by more users inside MS. I'll also > > reach out to the Git for Windows advocacy group to see if they have > > any ideas. > > > > I have not had time to figure out the inner workings of Tcl/Tk. Is > > there any way to turn on tracing/logging in Git for which commands are > > being called by gitk? > > Thank you for reaching out with detailed information internally, I am > happy to report that together with the help of Max Kirillov, this is now > resolved and a snapshot is available from > https://wingit.blob.core.windows.net/files/index.html that has the fix. > > Ciao, > Johannes > > > On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew <bret@corthon.com> wrote: > > > > > > On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin > > > <Johannes.Schindelin@gmx.de> wrote: > > > > > > > > Hi Bret, > > > > > > > > in that case, please try to find a way to trace the commands in a Tcl/Tk > > > > program (which gitk is) and see which command triggers the error. > > > > > > Er... that's a little out of my depth. I'll see if I can find time to learn. > > > Meanwhile, is there any way to request better instrumentation for the > > > error dialog so this data could have been collected for me? > > > > > > > > > > > Ciao, > > > > Johannes > > > > > > > > > > > > On Wed, 9 Jan 2019, Bret Barkelew wrote: > > > > > > > > > Will try to reply in-line, when appropriate. > > > > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still > > > > > has the issue. > > > > > > > > > > - Bret > > > > > > > > > > > > > > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin > > > > > <Johannes.Schindelin@gmx.de> wrote: > > > > > > > > > > > > Hi Bret, > > > > > > > > > > > > > > > > > > On Thu, 3 Jan 2019, Bret Barkelew wrote: > > > > > > > > > > > > > They are the exact same path (with a different drive letter). > > > > > > > > > > > > [it's a bit hard to follow the thread if you top-post a reply to an > > > > > > inline-replied answer, maybe imitate the style of other mails in the > > > > > > future.] > > > > > > > > > > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1 > > > > > > > and installed 2.19.0 on the failing system, and the older version of > > > > > > > Git works. > > > > > > > I've also tried a suggested fix I saw elsewhere to enable long path > > > > > > > names in the Windows registry, which did not resolve the issue with > > > > > > > git 2.20.1. > > > > > > > > > > > > > > Happy to collect any additional data. > > > > > > > > > > > > Please try the latest snapshot at > > > > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug > > > > > > might be fixed via > > > > > > https://github.com/git-for-windows/MINGW-packages/pull/32). > > > > > > > > > > > > Ciao, > > > > > > Johannes > > > > > > > > > > > > > - Bret > > > > > > > > > > > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote: > > > > > > > > > > > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote: > > > > > > > >> > > > > > > > >> When I open gitk in a particular repository under this version of Git > > > > > > > >> for Windows, I now get a dialog box that says "Error: couldn't execute > > > > > > > >> "git": file name too long". I've noticed that the most pronounced > > > > > > > >> effect is that I cannot see the file diffs (or sometimes the file name > > > > > > > >> list) for any of the commits. I don't know the exact repro, but I've > > > > > > > >> narrowed down the following things: > > > > > > > >> > > > > > > > >> - This does not happen with the same repo if I use a system that has > > > > > > > >> git 2.19.0.windows.1 on another machine. > > > > > > > >> - This does not happen on my current machine in a freshly cloned repo. > > > > > > > > > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > >> > > > > > > > >> However, as soon as the remote updates with any changes on a given > > > > > > > >> fetch/pull, the repo is put in a bad state permanently. > > > > > > > >> > > > > > > > >> I've pasted the output from gitk below... > > > > > > > >> > > > > > > > >> couldn't execute "git": file name too long > > > > > > > >> couldn't execute "git": file name too long > > > > > > > >> while executing > > > > > > > >> "open $cmd r" > > > > > > > >> (procedure "getallcommits" line 48) > > > > > > > >> invoked from within > > > > > > > >> "getallcommits" > > > > > > > >> (procedure "readcache" line 80) > > > > > > > >> invoked from within > > > > > > > >> "readcache file827e200" > > > > > > > >> ("eval" body line 1) > > > > > > > >> invoked from within > > > > > > > >> "eval $script" > > > > > > > >> (procedure "dorunq" line 11) > > > > > > > >> invoked from within > > > > > > > >> "dorunq" > > > > > > > >> ("after" script) > > > > > > > >> > > > > > > > >> Happy to gather whatever data needed. > > > > > > > >> Thanks! > > > > > > > >> - Bret Barkelew > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: git version 2.20.1.windows.1 throws file name too long in gitk 2019-05-29 16:40 ` Bret Barkelew @ 2019-05-29 18:07 ` Johannes Schindelin 0 siblings, 0 replies; 10+ messages in thread From: Johannes Schindelin @ 2019-05-29 18:07 UTC (permalink / raw) To: Bret Barkelew; +Cc: Bryan Turner, git [-- Attachment #1: Type: text/plain, Size: 6791 bytes --] Hi Bret, On Wed, 29 May 2019, Bret Barkelew wrote: > I know it's an incredibly late reply, but I have not seen this issue > reappear since the patches. Thank you very much for helping! It might be late, but it is even more welcome! Thanks for the feedback (and I am particularly happy that it works for you). Ciao, Johannes P.S.: For lurkers, I just realized that I never linked to the patches: https://github.com/git-for-windows/git/pull/2170 As this PR really only touches code that is already in Git for Windows, but not yet in git.git, I think I'll try to find some time post-v2.22.0 to brush up those gitk patches and contribute them to the Git mailing list for review. > On Sat, Apr 27, 2019 at 4:20 PM Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > > > > Hi Bret, > > > > On Thu, 18 Apr 2019, Bret Barkelew wrote: > > > > > This issue is now being reported by more users inside MS. I'll also > > > reach out to the Git for Windows advocacy group to see if they have > > > any ideas. > > > > > > I have not had time to figure out the inner workings of Tcl/Tk. Is > > > there any way to turn on tracing/logging in Git for which commands are > > > being called by gitk? > > > > Thank you for reaching out with detailed information internally, I am > > happy to report that together with the help of Max Kirillov, this is now > > resolved and a snapshot is available from > > https://wingit.blob.core.windows.net/files/index.html that has the fix. > > > > Ciao, > > Johannes > > > > > On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew <bret@corthon.com> wrote: > > > > > > > > On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin > > > > <Johannes.Schindelin@gmx.de> wrote: > > > > > > > > > > Hi Bret, > > > > > > > > > > in that case, please try to find a way to trace the commands in a Tcl/Tk > > > > > program (which gitk is) and see which command triggers the error. > > > > > > > > Er... that's a little out of my depth. I'll see if I can find time to learn. > > > > Meanwhile, is there any way to request better instrumentation for the > > > > error dialog so this data could have been collected for me? > > > > > > > > > > > > > > Ciao, > > > > > Johannes > > > > > > > > > > > > > > > On Wed, 9 Jan 2019, Bret Barkelew wrote: > > > > > > > > > > > Will try to reply in-line, when appropriate. > > > > > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still > > > > > > has the issue. > > > > > > > > > > > > - Bret > > > > > > > > > > > > > > > > > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin > > > > > > <Johannes.Schindelin@gmx.de> wrote: > > > > > > > > > > > > > > Hi Bret, > > > > > > > > > > > > > > > > > > > > > On Thu, 3 Jan 2019, Bret Barkelew wrote: > > > > > > > > > > > > > > > They are the exact same path (with a different drive letter). > > > > > > > > > > > > > > [it's a bit hard to follow the thread if you top-post a reply to an > > > > > > > inline-replied answer, maybe imitate the style of other mails in the > > > > > > > future.] > > > > > > > > > > > > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1 > > > > > > > > and installed 2.19.0 on the failing system, and the older version of > > > > > > > > Git works. > > > > > > > > I've also tried a suggested fix I saw elsewhere to enable long path > > > > > > > > names in the Windows registry, which did not resolve the issue with > > > > > > > > git 2.20.1. > > > > > > > > > > > > > > > > Happy to collect any additional data. > > > > > > > > > > > > > > Please try the latest snapshot at > > > > > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug > > > > > > > might be fixed via > > > > > > > https://github.com/git-for-windows/MINGW-packages/pull/32). > > > > > > > > > > > > > > Ciao, > > > > > > > Johannes > > > > > > > > > > > > > > > - Bret > > > > > > > > > > > > > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote: > > > > > > > > > > > > > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote: > > > > > > > > >> > > > > > > > > >> When I open gitk in a particular repository under this version of Git > > > > > > > > >> for Windows, I now get a dialog box that says "Error: couldn't execute > > > > > > > > >> "git": file name too long". I've noticed that the most pronounced > > > > > > > > >> effect is that I cannot see the file diffs (or sometimes the file name > > > > > > > > >> list) for any of the commits. I don't know the exact repro, but I've > > > > > > > > >> narrowed down the following things: > > > > > > > > >> > > > > > > > > >> - This does not happen with the same repo if I use a system that has > > > > > > > > >> git 2.19.0.windows.1 on another machine. > > > > > > > > >> - This does not happen on my current machine in a freshly cloned repo. > > > > > > > > > > > > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > >> > > > > > > > > >> However, as soon as the remote updates with any changes on a given > > > > > > > > >> fetch/pull, the repo is put in a bad state permanently. > > > > > > > > >> > > > > > > > > >> I've pasted the output from gitk below... > > > > > > > > >> > > > > > > > > >> couldn't execute "git": file name too long > > > > > > > > >> couldn't execute "git": file name too long > > > > > > > > >> while executing > > > > > > > > >> "open $cmd r" > > > > > > > > >> (procedure "getallcommits" line 48) > > > > > > > > >> invoked from within > > > > > > > > >> "getallcommits" > > > > > > > > >> (procedure "readcache" line 80) > > > > > > > > >> invoked from within > > > > > > > > >> "readcache file827e200" > > > > > > > > >> ("eval" body line 1) > > > > > > > > >> invoked from within > > > > > > > > >> "eval $script" > > > > > > > > >> (procedure "dorunq" line 11) > > > > > > > > >> invoked from within > > > > > > > > >> "dorunq" > > > > > > > > >> ("after" script) > > > > > > > > >> > > > > > > > > >> Happy to gather whatever data needed. > > > > > > > > >> Thanks! > > > > > > > > >> - Bret Barkelew > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-05-29 18:07 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-01-04 2:21 git version 2.20.1.windows.1 throws file name too long in gitk Bret Barkelew [not found] ` <CAGyf7-HcncFOfmm5McEkOvCTkHNdePDSEQDZwEAK=z1bmC=QKw@mail.gmail.com> 2019-01-04 3:38 ` Bret Barkelew 2019-01-09 18:39 ` Johannes Schindelin 2019-01-09 18:48 ` Bret Barkelew 2019-01-10 15:19 ` Johannes Schindelin 2019-01-10 18:55 ` Bret Barkelew 2019-04-18 18:16 ` Bret Barkelew 2019-04-27 23:20 ` Johannes Schindelin 2019-05-29 16:40 ` Bret Barkelew 2019-05-29 18:07 ` Johannes Schindelin
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).