Re: Implement core.symlinks to support filesystems without symlinks

From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Date: Feb 28, 2007, 22:48 UTC
Message-ID: <200702282348.51478.robin.rosenberg.lists@dewire.com>
In-Reply-To: <Pine.LNX.4.63.0702280101560.22628@wbgn013.biozentrum.uni-wuerzburg.de>

onsdag 28 februari 2007 01:07 skrev Johannes Schindelin:

>>
> Basically, there is no proper way to solve it (other than switching to 
> Linux, but that goes without saying).

> Your solution would fall short if one of the two files is changed. Since 
> they are supposed to be symlinks, the application expects them to be 
> identical, and weird sh*t happens.

As will it when the file contain something completly different than expected. Another SCM does copies instead and that works, though it's not very beautiful, but the checkout "works" 99% of the time, rather than not at all. As you code Most apps won't care if the original and the copy are different, but the user may notice (or not...).

> E.g. if you have a symlink "ln -s Makefile.host Makefile", and a script 
> which changes "Makefile.host", and a subdirectory Makefile accessing the 
> root Makefile, you will not be happy.

If...

> So, any way you go, if you have a repository containing symlinks, and you 
> have an OS which does not support symlinks, you are screwed.

As I said, I've seen the scheme sort of work. I can still work with the checkout, though not entirely as I would like to work (but that includes the platform too). All tools can use a copy, none can use a textfile containing the pointed to file.

Show 7 quoted lines

> But since we already have a symlink in git.git, and _want_ to compile git 
> on MinGW nevertheless, we should support symlinks _somehow_. Even if that 
> means that advanced usage of symlinks will fail.
> 
> I agree with Johannes here how to go about this partial "support" of 
> symlinks, since I cannot think of any sane way to retain the information 
> (where the symlink points to) in the index.

Don't update the symblink. We know it's a link. You don't want to anyway in your non-symlink supporting environment, or add git-ln.

-- robin