Re: Implement core.symlinks to support filesystems without symlinks

From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Date: Mar 1, 2007, 11:56 UTC
Message-ID: <200703011256.50659.robin.rosenberg.lists@dewire.com>
In-Reply-To: <Pine.LNX.4.63.0703010213420.22628@wbgn013.biozentrum.uni-wuerzburg.de>

torsdag 01 mars 2007 02:18 skrev Johannes Schindelin:

Show 19 quoted lines

> My points are these:
> 
> - If your project depends on symlinks, and you are on a system that does 
>   not do symlinks, you're screwed. However, you might want to checkout the 
>   project nevertheless.
> 
> - If you have a symlink, and your system does not do symlinks, you want 
>   the information where the symlink points to, at least _somewhere_. 
>   Without digging deep into Git internals.
> 
> - If you have a symlink, and your system ..., you want it to fail _early_.
> 
> The last point is reaaaaally important. There is a reason why we have 
> compiler errors, instead of just blindly compiling it, and if that 
> particular code path is triggered, explode in the face of the user.
> 
> So, all I would like to do on top of Johannes' patch is to add a _big_ 
> _fat_ warning whenever Git realizes it has to substitute a file for a 
> link, but I DON'T WANT THE BLOODY FILE TO BE COPIED.

I do want it to fail early initially (checkout), no default workaround, until I SAY I want copies (or text links, this is apparently a preference. By default git should complain loudly that it cannot create links.

- What do you want to do today?
	a) Screw me with copies
	b) Screw me with text links
	c) Screw me with shortcuts (cygwin does this which is fine as long as I stay 
within cygwin, so it is ok as a default behaviour there, but not otherwise)

I case of a link pointing to / I certainly do not want a copy either. :). There is no sane way of figuring out what I want.

-- robin