Re: Re: git clone doesn't work in symlink dir roots on Windows

I really don't know Jesse, 

The permissions issue keeps coming up, but to me it seems a non-issue as there is a CLI command to issue the appropriate permissions to a user. The directory link being separate is a painful but known issue, and my solution should work in most every-day ways, as long as the symlinks aren't dangling within the repository tree itself.

We could possibly limit the types of NTFS symbolic links that would actually be embedded in a git database to relative links (or is that done already?). I'm quite happy to have 'That type of NTFS symbolic link is not supported' as a valid solution to anything that is outside of simple symbolic links.

Currently the biggest thing holding symlinks back from being complete is lack of support in MSYS itself - which might be solved by using MSYS2. I have worked around this in the tests by overriding various commands with shell functions that implement operations on symlinks via cmd.exe. The only current exception to this is tar, which I can't do much about.

I've just rebased my symlink branch onto pt/tentative-1.8.4 and am chasing down test failures.

The tests like to make the symlinks before creating directories, or to create dangling symlinks, which doesn't help my cause - but am working through it.

//. 

On 23.08.2013 12:12, MNGoldenEagle wrote: 

from having to specify whether or not the symbolic link points to a file or directory, what are the limitations of symlinks? I'm a bit curious, having used them myself but never encountering any significant issues with them. I remember hearing at one point that Windows Vista could only create up to 31 links inside a directory, but I just checked on my Windows 7 machine and was able to generate over 600 links to a directory without a problem, so I'm guessing Windows 7 worked around this issue.

<michael@frog.wheelycreek.net> wrote:

is directly supported by the work I've already done

https://github.com/frogonwheels/git [1]

that there

that symlinks NOT be

people are against

well I guess I do - it's

means that symlinks like this example where they are

repository are supported. Secondly it means that people who are

prepared to accept the limitations will be able to use (or at least clone)

painful limitations is that windoze symlinks need to be marked

directories at the time of creation. The code I have implemented does it's

repository

can be

permanent

Aug 2013 06:34:59 PM Fredrik Gustafsson wrote:

at 07:22:03PM +0300, Sedat Kapanoglu wrote:

intense program, so this setup is not sane at all. With

said I know that git on windows historically had problems with

working on smb-mounted shares (sometimes you're forced to have stupid

since

directory. Repro steps:

symdir actualdir

Invalid symlink 'D:/gitto': Function not implemented

Thanks,

this is a symlink error, it seams

in the msysgit version of msysgit.

a implementation of readlink() according to:

http://mingw.5.n7.nabble.com/Replacement-for-readlink-td30679.html [2]

this is

(In the git source code the readlink call in this abspath.c)

pretend to know who is subscribed and who is not) ***

avoid top-posting. ***

https://github.com/msysgit/msysgit/wiki [3] - Github accounts are free.

Google

to msysgit@googlegroups.com

email to

and view previous threads, visit this group at

http://groups.google.com/group/msysgit?hl=en_US?hl=en [4]

You received this message because you are subscribed to the Google Groups "msysGit" group.

receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.

https://groups.google.com/groups/opt_out [5].

Links: ------ [1] https://github.com/frogonwheels/git [2] http://mingw.5.n7.nabble.com/Replacement-for-readlink-td30679.html [3] https://github.com/msysgit/msysgit/wiki [4] http://groups.google.com/group/msysgit?hl=en_US?hl=en [5] https://groups.google.com/groups/opt_out