symbolic link management in git-archive

Hi,

I guess the answer is "no" or "not yet", but is there a way to tell the zip
backend of git-archive to follow symbolic links rather than to store them?

Sergio

On Thu, Mar 27, 2008 at 11:29:28AM +0000, Sergio Callegari [off-list ref] wrote:

I guess the answer is "no" or "not yet", but is there a way to tell the zip
backend of git-archive to follow symbolic links rather than to store them?

how would that handle a '. -> foo' symlink? following such a recursion
would lead to an infinite loop, i guess.

Hi,

On Thu, 27 Mar 2008, Miklos Vajna wrote:

On Thu, Mar 27, 2008 at 11:29:28AM +0000, Sergio Callegari [off-list ref] wrote:

quoted

I guess the answer is "no" or "not yet", but is there a way to tell the zip
backend of git-archive to follow symbolic links rather than to store them?

how would that handle a '. -> foo' symlink? following such a recursion
would lead to an infinite loop, i guess.

Don't forget '/ -> foo'.

Ciao,
Dscho

Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:

Hi,

On Thu, 27 Mar 2008, Miklos Vajna wrote:

quoted

On Thu, Mar 27, 2008 at 11:29:28AM +0000, Sergio Callegari <sergio.callegari

<at> gmail.com> wrote:

quoted

quoted

I guess the answer is "no" or "not yet", but is there a way to tell the zip
backend of git-archive to follow symbolic links rather than to store them?

how would that handle a '. -> foo' symlink? following such a recursion
would lead to an infinite loop, i guess.

Don't forget '/ -> foo'.

Ciao,
Dscho

My question was inspired by the fact that the unix version of the zip program
has a switch, precisely to decide whether to follow or to store links.
I believe that the reason why this switch exist is clear: for some mysterious
reason the world is populated by OSs that do not understand symlinks and while
someone finds out why it is sensible to have workarounds. Obviously zip archives
with stored links are completely useless on these OSs.
BTW, note that also tar has a similar switch.
 
I believe that cases like the foo -> . or the foo -> /  (or even foo -> ..) can
be solved by either:

- limiting the symlink dereferentiation only to symlinks pointing to plain files

or

- leaving it to the user not to ask for link following when he knows that he has
such types of links

Personally I prefer the second. In the end:
- If these types of link exist, it is clear that the git-managed-stuff is not
made for certain OSs, so the user should know that asking for link following
makes no sense
- The user should know that there are some commands that might be dangerous
(think rm -fr ~), just warn them in the manual.
- The maximum risk here is to have the command never stop and fill the disk.

Sergio