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:
>
>  Aside 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.
>
> Jesse
>
>
> On Tue, Aug 20, 2013 at 2:30 AM, Michael Geddes <
> michael@frog.wheelycreek.net> wrote:
>
>> This type of functionality is directly supported by the work I've already
>> done
>> on symlinks here:   https://github.com/frogonwheels/git
>> (branches mrg/symlink-v*  )
>>
>> Even if we agree that symlinks only work to a limited degree, or that
>> there
>> are definite limitations, and that the default should be that symlinks
>> NOT be
>> supported within repositories, I'm not sure why people are against
>> incorporating what I've already implemented.. ok well I guess I do - it's
>> about time.
>>
>> Firstly, at the least it means that symlinks like this example where they
>> are
>> outside the repository are supported.  Secondly it means that people who
>> are
>> prepared to accept the limitations will be able to use (or at least clone)
>> repositories containing symlinks.
>>
>> One of the big, painful limitations is that windoze symlinks need to be
>> marked
>> as directories at the time of creation.  The code I have implemented does
>> it's
>> level best to create the correct type of NTFS symlink based on repository
>> information and falling back on filesystem information.
>>
>> The argument about permissions is only partially valid, since that can be
>> granted as an individual permission to the user without permanent
>> administrator rights.
>>
>> //.ichael G.
>>
>> On Sat, 10 Aug 2013 06:34:59 PM Fredrik Gustafsson wrote:
>> > On Sat, Aug 10, 2013 at 07:22:03PM +0300, Sedat Kapanoglu wrote:
>> > > > git is a disk intense program, so this setup is not sane at all.
>> With
>> > > > that said I know that git on windows historically had problems with
>> > > > working on smb-mounted shares (sometimes you're forced to have
>> stupid
>> > > > setups). I doubt that git really is the right tool for your work,
>> since
>> > >
>> > > I reproduced the same problem in a regular symlink directory. Repro
>> steps:
>> > >
>> > > mkdir actualdir
>> > > mklink /d symdir actualdir
>> > > cd symdir
>> > > git init .
>> > >
>> > > fatal: Invalid symlink 'D:/gitto': Function not implemented
>> > >
>> > > Thanks,
>> > >
>> > > Sedat
>> >
>> > Good, then we can determinate that this is a symlink error, it seams
>> > that readlink() isn't implemented in the msysgit version of msysgit.
>> >
>> > However msysgit should have a implementation of readlink() according to:
>> > http://mingw.5.n7.nabble.com/Replacement-for-readlink-td30679.html
>> >
>> > I've CC:ed the msysgit-maillist so that they can decide if this is
>> > something they want to address in newer releases.
>> >
>> > (In the git source code the readlink call in this abspath.c)
>>
>> --
>>  --
>> *** Please reply-to-all at all times ***
>> *** (do not pretend to know who is subscribed and who is not) ***
>> *** Please avoid top-posting. ***
>> The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki -
>> Github accounts are free.
>>
>> You received this message because you are subscribed to the Google
>> Groups "msysGit" group.
>> To post to this group, send email to msysgit@googlegroups.com
>> To unsubscribe from this group, send email to
>> msysgit+unsubscribe@googlegroups.com
>> For more options, and view previous threads, visit this group at
>> http://groups.google.com/group/msysgit?hl=en_US?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "msysGit" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to msysgit+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>