From: Christian Thaeter <ct@pipapo•org>
To: git@vger•kernel.org
Subject: handling symlinks proposal
Date: Sun, 26 Nov 2006 17:59:36 +0100 [thread overview]
Message-ID: <4569C7F8.4030303@pipapo.org> (raw)
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.
What are are the diffrent kinds of symlinks:
- they can point to a file local to the tree
- or point to a file outside of the tree
- they can be absolute
- or relative
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?
make config options (defaults in [core] ?)
symlink[.{local|extern}?_?{absolute|relative}?] = action
per branch overrides in [branch]
Example:
[core]
# in-tree symlinks shall not break a checkout to another place
symlink.local = relative
# we don't want out-of-tree symlinks, store them as file
symlink.extern_absolute = file
# a relative symlink out-of-tree is likely a typo/error?
symlink.extern_relative = error
[branch]
# some local feature branch keeps all symlinks
myfeature.symlink = keep
Default will be 'keep' so without this options it is what git currently
does.
Additional thoughts:
An existing symlink in the tree is not altered by check in, only the
repository is affected.
New checkouts or switching branches may alter it.
Merging between branches where one stores something as file and the
other symlink should be straightforward, does this need to be resolved?
So far thats just an idea how I would like it. If People like it this
way or we can refine it even better, I am going to implement it sometime
next.
next reply other threads:[~2006-11-26 16:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-26 16:59 Christian Thaeter [this message]
2006-11-26 18:25 ` handling symlinks proposal René Scharfe
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=4569C7F8.4030303@pipapo.org \
--to=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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox