Re: handling symlinks proposal

On Sun, 26 Nov 2006, Christian Thaeter wrote:

I can pretty much guarantee that you really don't want to do this, and that you'd be _much_ happier using some explicit wrappers around git to handle your special needs, than try to teach the SCM to handle symlinks specially.

The issues become all the same as with some of the idiotic things that other SCM's do - like $Id keyword substitution - but _much_ worse.

A simple example: what is "git diff HEAD" supposed to say, once you've committed the symlink as something else than a symlink? It's obviously still a symlink in your source tree.. Or what about "git reset --hard", or "git checkout other-branch-that-also-had-a-symlink"?

In other words, trivial and simple operations that have clear and well-defined semantics suddenly become totally insane, with no semantics that make sense what-so-ever.

By not "keeping" symlinks as symlinks, what you actually did was to totally destroy the ability to handle symlinks AT ALL. The simplest core operations suddenly cannot work, because you've broken the 1:1 link between "original source tree" and "tree that actually got committed".

Right. This is the only sane thing, if you want to support symlinks at all.

This is what some other systems do, by just not knowing anything about symlinks at all. It's certainly self-consistent - you can just drop all "lstat()" calls, and replace them with regular "stat()" calls.

It causes:

 - (obviously) inability to handle symlinks correctly

 - security problems and serious confusion when you _do_ have a symlink
   (what happens when you check out another branch, and the symlink points 
   to outside the tree? A system that is truly unaware of symlinks will 
   generally just overwrite the file OUTSIDE the tree, which is clearly 
   bogus, but equally bogus is to just do an "unlink + create" which will 
   break the symlink.

so it's generally MUCH worse than any alternative.

Neither of these make any real sense. You can really only store it in the form it is now, because you simply _cannot_ make it a "relative" or "absolute" symlink (the transformation depends on how things are mounted).

Not to mention that you get all the problems with "what does 'git diff' mean?" that I already alluded to above..

Sure, we can just say "don't allow symlinks". This is probably what we'd have to do for a native Windows client, for example, or for anything else that simply doesn't support the concept (VMS port of git, anyone?).

Again, there's nothing wrong with this, but what's the point, really? Especially a big enough point to merit a per-branch config option?