Re: handling symlinks proposal

Christian Thaeter schrieb:

Git currently keep symlinks always as symlink, I would like to see some
optional functionality when handling symlinks.

Sometimes it is not intended to store information external to a source
tree in git. Problems are that it might break a checkout, just loosing
information or even have security implications.

[...]

how can we handle symlinks:
 - 'keep' what git currently does, store the symlink as it is
 - 'file' store it as file (dereference it), information that it was a
    symlink gets lost, checkouts will produce a file.
 - 'relative' store it as a relative symlink
 - 'absolute' store it as a absolute symlink
 - 'error' refuse to checkin and abort commit
 - 'warn' display a warning

How to add this to git?

Why would we want to?  Could you perhaps give examples on how a symlink
in a git repo could break checkouts, cause loss of information or have
security implications?

You're symlink handling methods 'file', 'relative', 'absolute', 'error',
'warn' aren't very useful if you check in files (and symlinks) manually,
because if you add the links by hand then you can make sure they point
to the right place (or are no symlinks, but plain files), after all.

So they're mainly intended for initial checkins and merges with external
repos, right?  But in these cases you have to trust foreign code anyway
(simple example: you need to be sure 'make all' doesn't run a command
like 'rm -rf $HOME'), so you have to take a closer look at that stuff
anyway -- symlinks are just one part of what needs checking.

Thanks,