From: Sergio Callegari <sergio.callegari@gmail.com>
To: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
Cc: git@vger.kernel.org
Subject: Re: symbolic link management in git-archive
Date: Tue, 01 Apr 2008 00:12:09 +0200 [thread overview]
Message-ID: <47F161B9.1030408@gmail.com> (raw)
In-Reply-To: <47F14D4A.2020403@lsrfire.ath.cx>
René Scharfe wrote:
> Windows 2000 and up has support for symbolic links; it's just strangely
> restricted, [...] here's a good starting point for
> more information: http://en.wikipedia.org/wiki/NTFS_junction_point
>
> Arguably, your unzip program should create junction points for symlinks
> in zip files. I wouldn't be surprised if none of the existing ones
> support that, though;
>
> Would it be practical for you to distribute a junction point creation
> tool like Mark Russinovich's Junction (except that Junction's EULA
> forbids redistribution under most circumstances; see here:
> http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx)
> and a script that creates these symlinks for your audience?
>
Thank you very much for the detailed explanation. Unfortunately, I do
not think that Junction can be an option. My colleagues using Windows
tend to be a bit "conservative" about the tools they use. If they
navigate filesystem contents with the graphical tool, and they
look-at/expand the content of a zip file from explorer they expect that
it should be immediately right, otherwise there must be something wrong
in the way /I/ create zip files. They would not appreciate having to
unzip the file and then run an additional program on it to fix the
unzipped stuff.
> It's harder for git-archive to support following symlinks than for e.g.
> GNU tar. The reason is that the former operates on git objects, not
> files, directories or symlinks. In order to follow a symlink it would
> need to evaluate the symlink, follow it and then add actual files and
> directories to the archive.
>
> For your purposes, perhaps a slightly different implementation might be
> sufficient: namely to follow only relative symlinks that point to
> tracked objects. That way you still get a repeatable result and (most
> importantly) git-archive doesn't need to look at files and directories,
> it can stay safely in git land. Would such a way of operation be useful
> to you?
>
Absolutely positive. This would be already a great improvement,
fulfilling 99.9% of needs.
Sergio
prev parent reply other threads:[~2008-03-31 22:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-27 11:29 symbolic link management in git-archive Sergio Callegari
2008-03-27 11:40 ` Miklos Vajna
2008-03-27 11:44 ` Johannes Schindelin
2008-03-27 12:11 ` Sergio Callegari
2008-03-27 16:31 ` Junio C Hamano
2008-03-27 18:34 ` Sergio Callegari
2008-03-27 19:05 ` Junio C Hamano
2008-03-27 19:20 ` Sergio Callegari
2008-03-31 20:44 ` René Scharfe
2008-03-31 22:12 ` Sergio Callegari [this message]
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=47F161B9.1030408@gmail.com \
--to=sergio.callegari@gmail.com \
--cc=git@vger.kernel.org \
--cc=rene.scharfe@lsrfire.ath.cx \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.