public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed

From: "René Scharfe" <rene.scharfe@lsrfire•ath.cx>
To: Christian Thaeter <ct@pipapo•org>
Cc: git@vger•kernel.org
Subject: Re: handling symlinks proposal
Date: Sun, 26 Nov 2006 19:25:31 +0100	[thread overview]
Message-ID: <4569DC1B.9080400@lsrfire.ath.cx> (raw)
In-Reply-To: <4569C7F8.4030303@pipapo.org>

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,

next prev parent reply	other threads:[~2006-11-26 18:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-26 16:59 handling symlinks proposal Christian Thaeter
2006-11-26 18:25 ` René Scharfe [this message]
2006-11-26 18:46 ` Linus Torvalds
2006-11-26 19:50   ` Christian Thaeter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4569DC1B.9080400@lsrfire.ath.cx \
    --to=rene.scharfe@lsrfire$(echo .)ath.cx \
    --cc=ct@pipapo$(echo .)org \
    --cc=git@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox