Re: handling symlinks proposal

From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: Nov 26, 2006, 18:25 UTC
Message-ID: <4569DC1B.9080400@lsrfire.ath.cx>
In-Reply-To: <4569C7F8.4030303@pipapo.org>

Christian Thaeter schrieb:

Show 6 quoted lines

> 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.

[...]

Show 10 quoted lines

> 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,