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 [off-list ref] wrote:
On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew [off-list ref] wrote:
quoted
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.
quoted
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
From: Johannes Schindelin <hidden> Date: 2019-01-09 18:39:35
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.
- Bret
On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner [off-list ref] wrote:
quoted
On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew [off-list ref] wrote:
quoted
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.
quoted
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
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
[off-list ref] wrote:
Hi Bret,
On Thu, 3 Jan 2019, Bret Barkelew wrote:
quoted
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.]
quoted
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 [off-list ref] wrote:
quoted
On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew [off-list ref] wrote:
quoted
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.
quoted
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
From: Johannes Schindelin <hidden> Date: 2019-01-10 15:20:18
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
[off-list ref] wrote:
quoted
Hi Bret,
On Thu, 3 Jan 2019, Bret Barkelew wrote:
quoted
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.]
quoted
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 [off-list ref] wrote:
quoted
On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew [off-list ref] wrote:
quoted
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.
quoted
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
On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin
[off-list ref] 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:
quoted
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
[off-list ref] wrote:
quoted
Hi Bret,
On Thu, 3 Jan 2019, Bret Barkelew wrote:
quoted
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.]
quoted
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 [off-list ref] wrote:
quoted
On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew [off-list ref] wrote:
quoted
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.
quoted
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
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 [off-list ref] wrote:
On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin
[off-list ref] wrote:
quoted
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?
quoted
Ciao,
Johannes
On Wed, 9 Jan 2019, Bret Barkelew wrote:
quoted
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
[off-list ref] wrote:
quoted
Hi Bret,
On Thu, 3 Jan 2019, Bret Barkelew wrote:
quoted
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.]
quoted
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 [off-list ref] wrote:
quoted
On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew [off-list ref] wrote:
quoted
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.
quoted
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
From: Johannes Schindelin <hidden> Date: 2019-04-27 23:20:57
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 [off-list ref] wrote:
quoted
On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin
[off-list ref] wrote:
quoted
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?
quoted
Ciao,
Johannes
On Wed, 9 Jan 2019, Bret Barkelew wrote:
quoted
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
[off-list ref] wrote:
quoted
Hi Bret,
On Thu, 3 Jan 2019, Bret Barkelew wrote:
quoted
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.]
quoted
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 [off-list ref] wrote:
quoted
On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew [off-list ref] wrote:
quoted
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.
quoted
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
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
[off-list ref] wrote:
Hi Bret,
On Thu, 18 Apr 2019, Bret Barkelew wrote:
quoted
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
quoted
On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew [off-list ref] wrote:
quoted
On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin
[off-list ref] wrote:
quoted
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?
quoted
Ciao,
Johannes
On Wed, 9 Jan 2019, Bret Barkelew wrote:
quoted
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
[off-list ref] wrote:
quoted
Hi Bret,
On Thu, 3 Jan 2019, Bret Barkelew wrote:
quoted
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.]
quoted
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 [off-list ref] wrote:
quoted
On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew [off-list ref] wrote:
quoted
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.
quoted
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
From: Johannes Schindelin <hidden> Date: 2019-05-29 18:07:57
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
[off-list ref] wrote:
quoted
Hi Bret,
On Thu, 18 Apr 2019, Bret Barkelew wrote:
quoted
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
quoted
On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew [off-list ref] wrote:
quoted
On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin
[off-list ref] wrote:
quoted
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?
quoted
Ciao,
Johannes
On Wed, 9 Jan 2019, Bret Barkelew wrote:
quoted
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
[off-list ref] wrote:
quoted
Hi Bret,
On Thu, 3 Jan 2019, Bret Barkelew wrote:
quoted
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.]
quoted
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 [off-list ref] wrote:
quoted
On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew [off-list ref] wrote:
quoted
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.
quoted
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