Yes, about the git config core.longpaths true: works here as well. It requires git for windows > 1.9 to work. My 1.8.x choked, had to upgrade.
I have checked out the VM code where there was the GeniePlugin problem and the issue was gone with that setup. cp -r or rm -rf indeed give trouble. If we used the Windows subst command to map a drive to some depth in the path and work from there, it would solve the issue. That's how I've done that for Java never ending directories in the past. Operations are also very slow compared to Unix. Phil On Wed, Sep 30, 2015 at 6:47 PM, Dale Henrichs < dale.henri...@gemtalksystems.com> wrote: > > > On 09/29/2015 01:50 AM, Henrik Johansen wrote: > > > On 29 Sep 2015, at 1:48 , Dale Henrichs < > <dale.henri...@gemtalksystems.com>dale.henri...@gemtalksystems.com> wrote: > > The big issue for git and windows (in general) is that there is a 255 > character limit on the paths for files .... I recently pruned some file > names for Metacello (on a win-hack branch) just to get Metacello to work > with filetree .. > > Working with Github Desktop[1] for Windows makes the experience of using > git from the command line tolerable on Windows - you get a retty nice bash > shell to work with so as a non-windows user I can work in a pretty familiar > environment ... > > At the moment I'm working with Pharo3.0 on Windows, so I don't have any > useful feedback right now (assuming things have changed a bit on Windows > with Pharo4.0 and Pharo5.0) ... > > Dale > > > IIRC, there is some flag you can set to make (some?) the actual git client > (but not bundled tools) support long filenames on Windows: > git config core.longpaths true > For instance, cloning the PharoVM repo choked (or rather, failed > semi-silently) on some really long selector in an obscure plugin somewhere > until I found that... > > > Thanks Henry, I have done the `git config core.longpaths true` and I > believe that that (supposedly) addresses manipulating long file paths > problem for git, it does not help an application like pharo read the files > with long paths ... without additional work ... and even then it's not > clear that it truly fixes the problem ... because the fundamental limit is > embedded in the OS ... for example from the git bash shell, I cannot `rm` > the directories that have long paths (I have to use the explorer to delete > them) and when I write out a package with long paths from Pharo3.0 the long > path files are silently deleted ... > > If it worked for you, that's good ... my experience was not quite as nice:) > > Dale >
