Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes: > > Hi, > > On Thu, 27 Mar 2008, Miklos Vajna wrote: > > > On Thu, Mar 27, 2008 at 11:29:28AM +0000, Sergio Callegari <sergio.callegari <at> gmail.com> 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
