* 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
* 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).