On Sun, 26 Nov 2006, Christian Thaeter wrote: > > Git currently keep symlinks always as symlink, I would like to see some > optional functionality when handling symlinks. 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". > how can we handle symlinks: > - 'keep' what git currently does, store the symlink as it is Right. This is the only sane thing, if you want to support symlinks at all. > - 'file' store it as file (dereference it), information that it was a > symlink gets lost, checkouts will produce a file. 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. > - 'relative' store it as a relative symlink > - 'absolute' store it as a absolute symlink 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.. > - 'error' refuse to checkin and abort commit 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?). > - 'warn' display a warning 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? Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html