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